From report at bugs.python.org  Thu Jan  1 16:32:05 2015
From: report at bugs.python.org (Vandana Rao)
Date: Thu, 01 Jan 2015 15:32:05 +0000
Subject: [docs] [issue13077] Unclear behavior of daemon threads on main
	thread exit
In-Reply-To: <1317396642.03.0.535538271179.issue13077@psf.upfronthosting.co.za>
Message-ID: <1420126325.53.0.82359388635.issue13077@psf.upfronthosting.co.za>


Vandana Rao added the comment:

On Windows8.1,this is not the situation.Irrespective of the thread being daemon or non-daemon,the process continues. The program doesn't terminate when daemon thread is being used.

----------
nosy: +Vandana.Rao

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

From report at bugs.python.org  Thu Jan  1 16:56:16 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Jan 2015 15:56:16 +0000
Subject: [docs] [issue13077] Unclear behavior of daemon threads on main
	thread exit
In-Reply-To: <1317396642.03.0.535538271179.issue13077@psf.upfronthosting.co.za>
Message-ID: <1420127776.08.0.0496869468274.issue13077@psf.upfronthosting.co.za>


R. David Murray added the comment:

etuardu: I think you rewording is indeed clearer.

Vandana: Please open a new issue with a reproducer.

----------
stage: patch review -> needs patch
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jan  1 20:32:46 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Jan 2015 19:32:46 +0000
Subject: [docs] [issue23144] html.parser.HTMLParser: setting
	'convert_charrefs =	True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1420140766.7.0.311727580158.issue23144@psf.upfronthosting.co.za>


Martin Panter added the comment:

You ?forgot? to call close():

>>> parser.close()
Encountered some data  :  eggs

Perhaps this is a documentation bug, since there is a lot of example code given, but none of the examples call close().

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

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

From report at bugs.python.org  Thu Jan  1 21:36:29 2015
From: report at bugs.python.org (Ross)
Date: Thu, 01 Jan 2015 20:36:29 +0000
Subject: [docs] [issue23144] html.parser.HTMLParser: setting
	'convert_charrefs =	True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1420144589.41.0.959965568567.issue23144@psf.upfronthosting.co.za>


Ross added the comment:

That would make sense.

Might also be worth mentioning the difference in behaviour with convert_charrefs = True/False as that was what led me to think this was a bug.

----------

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

From report at bugs.python.org  Fri Jan  2 13:02:17 2015
From: report at bugs.python.org (Jonathan Sharpe)
Date: Fri, 02 Jan 2015 12:02:17 +0000
Subject: [docs] [issue23149] Typo in PEP-0008 - "this PEP do not"
Message-ID: <1420200137.63.0.326007940364.issue23149@psf.upfronthosting.co.za>


Changes by Jonathan Sharpe <j.r.sharpe+python at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: fix_pep8_typo.patch
keywords: patch
nosy: docs at python, jonrsharpe
priority: normal
severity: normal
status: open
title: Typo in PEP-0008 - "this PEP do not"
type: enhancement
Added file: http://bugs.python.org/file37585/fix_pep8_typo.patch

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

From report at bugs.python.org  Fri Jan  2 16:03:14 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 02 Jan 2015 15:03:14 +0000
Subject: [docs] [issue23149] Typo in PEP-0008 - "this PEP do not"
Message-ID: <1420210994.48.0.285259138723.issue23149@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/issue23149>
_______________________________________

From report at bugs.python.org  Fri Jan  2 19:10:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Jan 2015 18:10:04 +0000
Subject: [docs] [issue23149] Typo in PEP-0008 - "this PEP do not"
Message-ID: <20150102180950.125886.93409@psf.io>


New submission from Roundup Robot:

New changeset 0c72bd524aed by Benjamin Peterson in branch 'default':
conjugate 'do' correctly (closes #23149)
https://hg.python.org/peps/rev/0c72bd524aed

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

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

From report at bugs.python.org  Fri Jan  2 21:16:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 02 Jan 2015 20:16:39 +0000
Subject: [docs] [issue22128] patch: steer people away from codecs.open
In-Reply-To: <1407071838.74.0.684483503953.issue22128@psf.upfronthosting.co.za>
Message-ID: <1420229799.56.0.7376746779.issue22128@psf.upfronthosting.co.za>


Martin Panter added the comment:

Just pointing out there is a patch for Issue 19548 for Python 3 which also adds a pointer to the builtin open() function and updates the codecs.open() caveats. That issue doesn?t touch Python 2 though.

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

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

From report at bugs.python.org  Fri Jan  2 23:13:42 2015
From: report at bugs.python.org (John Potelle)
Date: Fri, 02 Jan 2015 22:13:42 +0000
Subject: [docs] [issue23153] Clarify Boolean Clause Results
Message-ID: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za>


New submission from John Potelle:

>From v3.4 Tutorial section 5.7

It is possible to assign the result of a comparison or other Boolean expression to a variable. For example,
>>> string1, string2, string3 = '', 'Trondheim', 'Hammer Dance'
>>> string1 or string2 or string3
'Trondheim'
>>> bool(string1 or string2 or string3)
True

In most languages a Boolean clause (comparison) returns a Boolean or it's equivalent, not the last argument evaluated.  Please add a reference to bool function (or some better? method) in this section for clarification.

----------
assignee: docs at python
components: Documentation
messages: 233330
nosy: docs at python, jpotelle
priority: normal
severity: normal
status: open
title: Clarify Boolean Clause Results
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan  3 01:12:33 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Sat, 03 Jan 2015 00:12:33 +0000
Subject: [docs] [issue23153] Clarify Boolean Clause Results
In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za>
Message-ID: <1420243953.55.0.0422394423509.issue23153@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

A few questions/comments:

1. How would the reference clarify matters?

2. "Most languages" is perhaps overstating the matter. Lower level languages and strictly typed languages tend to return a boolean value, but many high level scripting languages (among them Perl, Python and JavaScript) return the last value evaluated.

3. Referencing the bool() constructor doesn't seem like it would add much, and might encourage the wrong behaviors; idiomatic Python rarely bothers to coerce to True/False because it's unnecessary extra work when an if or while condition can simply evaluate the "truthiness" of the value being tested without coercion. I kind of like the fact that it omits use of bool(), because down that road lies madness (if bool(a or b) == False: madness).

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

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

From report at bugs.python.org  Sat Jan  3 05:07:36 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 03 Jan 2015 04:07:36 +0000
Subject: [docs] [issue23153] Clarify Boolean Clause Results
In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za>
Message-ID: <1420258056.66.0.462246641987.issue23153@psf.upfronthosting.co.za>


Ethan Furman added the comment:

`or` does not return the last item evaluated -- it returns the first truthy item, or, if no truthy items, the last false item:

  --> 0 or {}
  {}
  --> 0 or 1 or {}
  1

----------
nosy: +ethan.furman

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

From report at bugs.python.org  Sat Jan  3 13:18:03 2015
From: report at bugs.python.org (Carol Willing)
Date: Sat, 03 Jan 2015 12:18:03 +0000
Subject: [docs] [issue23116] Python Tutorial 4.7.1: Improve ask_ok() to
	cover more	input values
In-Reply-To: <1419622934.77.0.489991713093.issue23116@psf.upfronthosting.co.za>
Message-ID: <1420287483.43.0.0264400480741.issue23116@psf.upfronthosting.co.za>


Carol Willing added the comment:

@amylou Thank you for submitting this documentation suggestion about the Python Tutorial.

This tutorial section, 4.7.1 Default Argument Values, tries to show that a function can have multiple input arguments which may be given default values.

While the suggestion to use lower() does offer more robust input handling, it also adds some complexity to the example by introducing another function to a possibly new user.

I do believe that the 'ask_ok' function could be improved by renaming the 'complaint' argument to something more positive, perhaps 'reminder'. I would also recommend replacing the error message 'uncooperative user' to something with a softer tone, perhaps 'invalid user response'.

@amyluo If you are interested in working on documentation, section 6 of the Developer Guide is a handy resource (https://docs.python.org/devguide/docquality.html).

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

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

From report at bugs.python.org  Sat Jan  3 14:19:57 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Jan 2015 13:19:57 +0000
Subject: [docs] [issue23153] Clarify Boolean Clause Results
In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za>
Message-ID: <1420291197.67.0.537629996368.issue23153@psf.upfronthosting.co.za>


R. David Murray added the comment:

Indeed, the short circuit and value return behavior is described in that section just before the example.

I agree with Joel.  This is a tutorial, and part of the zen of Python is that all expressions have a boolean value.  There are very few places in python programs where it would be considered Pythonic to "cast" a value to one of the two uniquely boolean values via the Bool operator, so it is better that it *not* be mentioned in this context.

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

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

From report at bugs.python.org  Sat Jan  3 17:00:38 2015
From: report at bugs.python.org (John Potelle)
Date: Sat, 03 Jan 2015 16:00:38 +0000
Subject: [docs] [issue23153] Clarify Boolean Clause Results
In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za>
Message-ID: <1420300838.61.0.821864153413.issue23153@psf.upfronthosting.co.za>


John Potelle added the comment:

I'm learning Python and informing you this is confusing - and you close the ticket without hearing any response to your questions?

Re: Josh
1. To show how to return a Boolean result from a Boolean clause. If there's a better way, I'm all for it.
2. "Most" is a generalization. Perhaps "Many" is a better term? All traditional 3GLs and some other scripting languages don't; e.g. REXX and Beanshell return Boolean. But it's not important here. 
3. As I said, "or some better method". I've been programming 30 years but am only now learning Python. All I asking for is better clarification in the tutorial. If this were a wiki I would add one myself.

Re: Ethan; quote from the line above, same section in the Tutorial:
"When used as a general value and not as a Boolean, the return value of a short-circuit operator is the last evaluated argument." If this isn't correct, please fix it. And this whole sentence is a bit weird to me - Boolean operators are *always* used in a Boolean context - unless the op is overloaded with some other functionality. Why would it return anything else? (well let's not go there...)

Re: R.David
Sorry I didn't see any input from "Joel". But, yes, this is a tutorial.

I argue that using A = (B or C or D) construct is not good, intuitive programming style, anyway. To me this looks like A should hold a Boolean, even only from a pseduocode standpoint. Even so, one wouldn't need to "cast" a Boolean if a Boolean was returned, as old programmers like me would expect. 

But, OK, so don't use bool() - but what you said is basically what I'm looking for IN the tutorial - eduction about why a Boolean should NOT be expected. Or how to achieve a Boolean, since it's a valid data type since version 2.3. This is a tutorial, after all.

For example, the full documentation for v3.4 section 4.1: "Operations and built-in functions that have a Boolean result always return 0 or False for false and 1 or True for true, unless otherwise stated. (Important exception: the Boolean operations or and and always return one of their operands.)". Even here the docs says this is an "exception".

----------

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

From report at bugs.python.org  Sat Jan  3 19:57:26 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 03 Jan 2015 18:57:26 +0000
Subject: [docs] [issue23153] Clarify Boolean Clause Results
In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za>
Message-ID: <1420311446.08.0.903743829548.issue23153@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Apologies, my wording was poor -- the last item evaluated is the one returned, but all items may not be evaluated.  As soon as the answer is known Python stops evaluating any remaining items.

So in the example:

  --> string1, string2, string3 = '', 'Trondheim', 'Hammer Dance'
  --> string1 or string2 or string3
  'Trondheim'

string2 is returned because it satifies the `or` conditions, and string3 is not evaluated.


Re: John

I appreciate you have many years of programming experience, but there are going to be differences between what is good practice in those languages and what is good practice in Python.  IMO, the big three differences are:

  - white space indentation
  - everything is an object (variables, functions, classes, instances,
    any piece of data...)
  - everything has a truthy of falsey value -- e.g.

    --> string1, string2, string3 = '', 'Trondheim', 'Hammer Dance'
    --> if string2:
    ...    print('string2 has a value!  It is %s' % string2)
    ...
    'string2 has a value!  It is Trondheim'

    notice there is no `if bool(string2)` or `if string2 == False` (which would be False).

As far as finding that bit of the tutorial confusing, there is no way to have a single document that is crystal clear to everyone who reads it.  This section is correct, as is section 4.1 -- `or` is being used, so the operand is returned, not True or False.

----------

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

From report at bugs.python.org  Sat Jan  3 22:55:24 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Jan 2015 21:55:24 +0000
Subject: [docs] [issue23156] Update tix install information in tkinter tix
	chapter of	doc
Message-ID: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Update tix install info in doc.  "Using tix" starts with 3 lines for testing one's tix install and continues 

'''If this fails, you have a Tk installation problem which must be resolved before proceeding. Use the environment variable TIX_LIBRARY to point to the installed Tix library directory, and make sure you have the dynamic object library (tix8183.dll or libtix8183.so) in the same directory that contains your Tk dynamic object library (tk8183.dll or libtk8183.so). The directory with the dynamic object library should also have a file called pkgIndex.tcl (case sensitive), which contains the line: package ifneeded Tix 8.1 [list load "[file join $dir tix8183.dll]" Tix]'''

Almost nothing above matches my working-with-tix 3.4.2 Win 7 install.  I do have a tix library directory: python34/tcl/tix8.4.3, but the version number is much newer.  Since it is in the right place, TIX_LIBRARY is not needed and there is none.  python34/DLLs contains tcl86t.dll and tk86t.dll and NO tix####.dll.  Is the once separate tix dll now part of tk dll?  I cannot find pkgIndex.tcl; it is certainly not in the DLLs directory nor in the /tcl.

The current doc seems useless to people who do not have tix working.  See, for example,
https://stackoverflow.com/questions/27751923/tix-widgets-installation-issue
which is a semi-repeat question and which claims seeing similar reports elsewhere on the net.

----------
assignee: docs at python
components: Documentation, Tkinter
messages: 233368
nosy: docs at python, serhiy.storchaka, terry.reedy, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Update tix install information in tkinter tix chapter of doc
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jan  3 22:56:27 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Jan 2015 21:56:27 +0000
Subject: [docs] [issue23156] Update tix install information in tkinter tix
	chapter of	doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1420322187.89.0.626877223444.issue23156@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Added Zach for Window build info, Ned for OSX info.

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

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

From report at bugs.python.org  Sat Jan  3 23:22:24 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Jan 2015 22:22:24 +0000
Subject: [docs] [issue23153] Clarify Boolean Clause Results
In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za>
Message-ID: <1420323744.12.0.455007651074.issue23153@psf.upfronthosting.co.za>


R. David Murray added the comment:

I mistyped 'josh' as 'joel', sorry.

Ethan covers it pretty well, but I'll add a few things.

Boolean operators are indeed not always used in a boolean context.  There is a long tradition in Python of using them to return values via the short-circuit mechanism.  Python is not the only language that does this.

That said, there are disadvantages to that use of boolean operators, and eventually the trinary expression 'x if y else z' was introduced, and is now the preferred way to compute such values.  The tutorial has not been updated to reflect that, and that is something that could be done, but probably requires a significant rewrite...someone on irc pointed out that the passage we are discussing is the first introduction of 'or' in the tutorial).  However, the short-circuit-and-value-returning behavior of the boolean operators will not change, since it is a long standing part of the language.

Your suggestion that this whole thing be discussed more is a valid point, but the question is, is this point in the tutorial the place to do it?  Again, a more extensive rewrite is probably needed in order to make a real improvement (a project that is being discussed, whose status I don't know).

Finally, the 4.1 text you quote is noting and/or as an exception is talking about the built-in functions and operators.  and and or are important exceptions both because their default is different from other logical operations and because, unlike the other python operators, a type cannot override them.  Thus they always return a value, whereas other *logical* operations will return a boolean *unless otherwise documented* in the documentation for the type.  (I'm not sure there are any exceptions to that in the sdtlib, but there are, for example, in numpy.)

Now, that all said, the tutorial section explicitly mentions the behavior of and and or, so I don't see how their being exceptional in this regard is an issue with the tutorial text.  If you assigned another logical expression to a variable, you'd get True or False, but in Python's philosophy that's just a special case of the fact that all values in python have a truth value, as discussed by Ethan.

So, in summary, I hear you that as an experienced programmer this tutorial section did not give you all the information you wanted.  However, it is a *tutorial*, and so it *can't* (and be a readable *tutorial*) cover all the issues.  Perhaps it could cover more if it were rewritten, but I don't think changing this section in any of the ways suggested so far would, as it is currently organized, be an improvement.  If anyone wants to take another stab at it, though, we'll definitely evaluate it.

willingc on IRC suggested adding links to other parts of the docs, for further reading, and that might be worthwhile if someone wants to take  a look at making a suggestion in that regard.

----------

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

From report at bugs.python.org  Sun Jan  4 02:10:04 2015
From: report at bugs.python.org (John Potelle)
Date: Sun, 04 Jan 2015 01:10:04 +0000
Subject: [docs] [issue23153] Clarify Boolean Clause Results
In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za>
Message-ID: <1420333804.36.0.330934551241.issue23153@psf.upfronthosting.co.za>


John Potelle added the comment:

Thank you for your reasoned responses. I'm beginning to see just how much Python is its own animal. This and/or thing has history; I get it. Links back to the reference documentation is a good idea.

----------

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

From report at bugs.python.org  Sun Jan  4 03:17:21 2015
From: report at bugs.python.org (Al Sweigart)
Date: Sun, 04 Jan 2015 02:17:21 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1420337841.2.0.848239981076.issue17583@psf.upfronthosting.co.za>


Changes by Al Sweigart <asweigart at gmail.com>:


----------
nosy: +Al.Sweigart

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

From report at bugs.python.org  Sun Jan  4 03:29:37 2015
From: report at bugs.python.org (Al Sweigart)
Date: Sun, 04 Jan 2015 02:29:37 +0000
Subject: [docs] [issue14944] Setup & Usage documentation for pydoc,
	idle & 2to3
In-Reply-To: <1338256058.02.0.10025521772.issue14944@psf.upfronthosting.co.za>
Message-ID: <1420338577.1.0.599813539348.issue14944@psf.upfronthosting.co.za>


Changes by Al Sweigart <asweigart at gmail.com>:


----------
nosy: +Al.Sweigart

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

From report at bugs.python.org  Sun Jan  4 10:29:41 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 04 Jan 2015 09:29:41 +0000
Subject: [docs] [issue23156] Update tix install information in tkinter tix
	chapter of	doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1420363781.47.0.584716304868.issue23156@psf.upfronthosting.co.za>


Ned Deily added the comment:

I'm no expert on Tk but, as best I can tell, Tix is a very old third-party set of Tk extension widgets that has been made obsolete by the Ttk widget set integrated into standard Tk 8.5. See, for example, Kevin Walzer's comments here: http://www.thecodingforums.com/threads/state-of-the-art-tkinter-tk-8-5-tix.651741/.

Unlike Ttk, Tix is not part of the core Tk distribution so whether or not Tix is available depends on the Tcl/Tk distribution in use.  For the Python Windows installer, we ship our own version of Tcl/Tk and include a version of Tix.

For the Python OS X installer, we currently do not ship our own version of Tcl/Tk, rather we depend on the user installing a third-party version of Tcl/Tk (we currently recommend ActiveState's ActiveTcl if the use is compatible with ActiveState's license) or falling back to an (old) Apple-supplied version of Tcl/Tk.  Neither Apple nor ActiveState include Tix by default.  However, ActiveTcl does include Tix in the Tcl Extension Archive (http://wiki.tcl.tk/17340) it maintains and provides a command-line program, teacup, to download, install, and manage TEA extensions, analogous to Python's pip.  So it's straightforward to install Tix if you are using ActiveTcl:

    sudo teacup install Tix

Unfortunately, A/S's OS X version of Tix currently downloadable via teacup is built as a 32-bit binary only.  The vast majority of users, running on up-to-date OS X systems, will run into another failure since their Python will likely be running in 64-bit mode:

>>> root = Tix.Tk()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tix.py", line 221, in __init__
    self.tk.eval('package require Tix')
_tkinter.TclError: dlopen(/Library/Tcl/teapot/package/macosx10.5-i386-x86_64/lib/Tix8.4.3/libTix8.4.3.dylib, 6): no suitable image found.  Did find:
	/Library/Tcl/teapot/package/macosx10.5-i386-x86_64/lib/Tix8.4.3/libTix8.4.3.dylib: mach-o, but wrong architecture

Depending on the Python instance in use, running a universal Python in 32-bit mode may be an option or installing a 32-bit-only Python can be done.  Either way, it's an unexpected hack.  I don't know whether there is a fundamental problem in building Tix for 64-bit on OS X but I think it is telling that there isn't one available from A/S.

Likewise, for other platforms, how you make Tix available, if at all, varies.  For example, Ubuntu and Debian distributions also do not install Tix by default but it can be installed via their standard package managers.

So, all in all, trying to document Tix installation is a major can of worms; I don't think we should be trying to do so in the Python documentation.  Further, it seems like we should be strongly discouraging use of Tix in favor of Ttk.

----------

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

From report at bugs.python.org  Sun Jan  4 14:19:32 2015
From: report at bugs.python.org (Eric O. LEBIGOT)
Date: Sun, 04 Jan 2015 13:19:32 +0000
Subject: [docs] [issue23164] "pydoc filter" documentation restrictive
Message-ID: <1420377572.43.0.335658121107.issue23164@psf.upfronthosting.co.za>


New submission from Eric O. LEBIGOT:

The pydoc documentation for filter reads:

    filter(function or None, sequence) -> list, tuple, or string
    
    Return those items of sequence for which function(item) is true.  If
    function is None, return the items that are true.  If sequence is a tuple
    or string, return the same type, else return a list.

It would be nicer to know (e.g. when offline and with no local access to the HTML documentation) that filter() can actually be used more generally with an iterable:

    filter(function or None, **iterable**) -> list, tuple, or string
    
    Return those items of **iterable** for which?

----------
assignee: docs at python
components: Documentation
messages: 233416
nosy: docs at python, lebigot
priority: normal
severity: normal
status: open
title: "pydoc filter" documentation restrictive
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan  4 15:13:01 2015
From: report at bugs.python.org (Gareth Rees)
Date: Sun, 04 Jan 2015 14:13:01 +0000
Subject: [docs] [issue20606] Operator Documentation Example doesn't work
In-Reply-To: <1392201634.78.0.0474474805722.issue20606@psf.upfronthosting.co.za>
Message-ID: <1420380781.79.0.382976717262.issue20606@psf.upfronthosting.co.za>


Gareth Rees added the comment:

This is a duplicate of #22180, which was fixed in changeset 9c250f34bfa3 by Raymond Hettinger in branch '3.4'. The fix just removes the bad example, as in my patch. So I suggest that this issue be closed as a duplicate.

----------

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

From report at bugs.python.org  Sun Jan  4 17:18:39 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 04 Jan 2015 16:18:39 +0000
Subject: [docs] [issue20606] Operator Documentation Example doesn't work
In-Reply-To: <1392201634.78.0.0474474805722.issue20606@psf.upfronthosting.co.za>
Message-ID: <1420388319.82.0.948793083452.issue20606@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Closed

----------
nosy: +asvetlov
resolution:  -> duplicate
stage:  -> resolved
superseder:  -> operator.setitem example no longer works in Python 3 due to lazy map

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

From report at bugs.python.org  Sun Jan  4 21:44:46 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Jan 2015 20:44:46 +0000
Subject: [docs] [issue23156] Update tix install information in tkinter tix
	chapter of	doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1420404286.55.0.0987569240186.issue23156@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I found tix8.4.3.dll and pkgIndex.tcl inside tcl/tix8.4.3, which is not where the doc currently says to look.

Christian Gollwitzer posted a response on the python-list thread "Python Tk Tix GUI documentation & builder overview and tips" (which helped inspire this issue in addition to the SO post).  He basically agrees with Ned's ending comment that "we should be strongly discouraging use of Tix in favor of Ttk."

"Note that Tix is LEGACY. There are much better options for its widgets available that are based on ttk. ... Not to mention that the Tix widgets are extremely ugly, while the widgets from ttk have a near-native look and feel."

So I agree that the opening paragraph of the (T)tkinter.tix section 
https://docs.python.org/3/library/tkinter.tix.html#module-tkinter.tix
should identify it as a legacy python interface to the old, optional, tcl/tk tix extension that has been mostly superceded by widgets added either directly to tk or by ttk.

Cristian also listed the ttk replacements.
'''
* Hierarchical Listbox use ttk::treeview, tablelist_tile or tkTreeCtrl, with increasing order of capabilities and install complexity

* TList: I think tkTreeCtrl can do it, never have used this layout

* CheckList: tablelist can be used with an editable field

* Grid widget: use tkTable

* NoteBook, PanedWindow, ComboBox, LabelFrame -> ttk::notebook, ttk::panedwindow, ttk::combobox, ttk::labelframe

* Balloon: tcllib::tooltip
'''

The tkinter and tkinter.ttk replacements could similarly be added to the tix widget listing in the doc.

----------

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

From report at bugs.python.org  Sun Jan  4 23:12:26 2015
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sun, 04 Jan 2015 22:12:26 +0000
Subject: [docs] [issue23167] Marshal docs say format version is 3;
	actual format version is 4
Message-ID: <1420409546.12.0.515201542018.issue23167@psf.upfronthosting.co.za>


New submission from Dmitry Kazakov:

Documentation on marshal module says that format version is 3, but Py_MARSHAL_VERSION is set to 4. Search for marshal-related issues gave me an idea that this is a documentation bug.

----------
assignee: docs at python
components: Documentation
files: marshal_doc.diff
keywords: patch
messages: 233429
nosy: docs at python, vlth
priority: normal
severity: normal
status: open
title: Marshal docs say format version is 3; actual format version is 4
versions: Python 3.4
Added file: http://bugs.python.org/file37598/marshal_doc.diff

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

From report at bugs.python.org  Sun Jan  4 23:17:50 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Jan 2015 22:17:50 +0000
Subject: [docs] [issue20606] Operator Documentation Example doesn't work
In-Reply-To: <1392201634.78.0.0474474805722.issue20606@psf.upfronthosting.co.za>
Message-ID: <1420409870.35.0.135810349589.issue20606@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


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

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

From report at bugs.python.org  Sun Jan  4 23:30:27 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Jan 2015 22:30:27 +0000
Subject: [docs] [issue23167] Marshal docs say format version is 3;
	actual format version is 4
In-Reply-To: <1420409546.12.0.515201542018.issue23167@psf.upfronthosting.co.za>
Message-ID: <20150104223022.125896.11936@psf.io>


Roundup Robot added the comment:

New changeset 8ac23d3242b4 by Benjamin Peterson in branch '3.4':
the current marshal version is 4 (closes #23167)
https://hg.python.org/cpython/rev/8ac23d3242b4

New changeset 826831a9a376 by Benjamin Peterson in branch 'default':
merge 3.4 (#23167)
https://hg.python.org/cpython/rev/826831a9a376

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

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

From report at bugs.python.org  Mon Jan  5 11:05:23 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 05 Jan 2015 10:05:23 +0000
Subject: [docs] [issue20487] Odd words in unittest.mock document.
In-Reply-To: <1391355507.86.0.158179018907.issue20487@psf.upfronthosting.co.za>
Message-ID: <1420452323.79.0.977693978732.issue20487@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here is a patch to address msg211296.

----------
keywords: +patch
nosy: +berker.peksag
stage:  -> patch review
type:  -> enhancement
versions:  -Python 3.3
Added file: http://bugs.python.org/file37602/issue20487.diff

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

From report at bugs.python.org  Mon Jan  5 11:09:07 2015
From: report at bugs.python.org (Michael Foord)
Date: Mon, 05 Jan 2015 10:09:07 +0000
Subject: [docs] [issue20487] Odd words in unittest.mock document.
In-Reply-To: <1391355507.86.0.158179018907.issue20487@psf.upfronthosting.co.za>
Message-ID: <1420452547.42.0.861378686055.issue20487@psf.upfronthosting.co.za>


Michael Foord added the comment:

Patch looks good, thanks.

----------

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

From report at bugs.python.org  Tue Jan  6 01:05:22 2015
From: report at bugs.python.org (Karl Richter)
Date: Tue, 06 Jan 2015 00:05:22 +0000
Subject: [docs] [issue23174] shelve.open fails with error "anydbm.error: db
	type	could not be determined"
Message-ID: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za>


New submission from Karl Richter:

`shelve.open(tempfile.mkstemp()[1])` fails with error "anydbm.error: db type could not be determined" which is not explainable with the docs. Traceback is

    Traceback (most recent call last):
      File "./cudaminer_param_checker.py", line 720, in <module>
        plac.call(cudaminer_param_checker)
      File "/usr/local/lib/python2.7/dist-packages/plac_core.py", line 309, in call
        cmd, result = parser_from(obj).consume(arglist)
      File "/usr/local/lib/python2.7/dist-packages/plac_core.py", line 195, in consume
        return cmd, self.func(*(args + varargs + extraopts), **kwargs)
      File "./cudaminer_param_checker.py", line 715, in cudaminer_param_checker
        visualize_cudaminer_param_checker_results_wxpython_gui()
      File "./cudaminer_param_checker.py", line 365, in visualize_cudaminer_param_checker_results_wxpython_gui
        frame = CudaminerParamChecker(None, )
      File "./cudaminer_param_checker.py", line 378, in __init__
        self.generator = CudaminerParamCheckerGenerator()
      File "./cudaminer_param_checker.py", line 160, in __init__
        self.result_dict= shelve.open(storage_file_path) 
      File "/usr/lib/python2.7/shelve.py", line 239, in open
        return DbfilenameShelf(filename, flag, protocol, writeback)
      File "/usr/lib/python2.7/shelve.py", line 223, in __init__
        Shelf.__init__(self, anydbm.open(filename, flag), protocol, writeback)
      File "/usr/lib/python2.7/anydbm.py", line 82, in open
        raise error, "db type could not be determined"
    anydbm.error: db type could not be determined

----------
assignee: docs at python
components: Documentation
messages: 233488
nosy: docs at python, krichter
priority: normal
severity: normal
status: open
title: shelve.open fails with error "anydbm.error: db type could not be determined"
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan  6 01:12:21 2015
From: report at bugs.python.org (Karl Richter)
Date: Tue, 06 Jan 2015 00:12:21 +0000
Subject: [docs] [issue23174] shelve.open fails with error "anydbm.error: db
	type	could not be determined"
In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za>
Message-ID: <1420503141.27.0.822737050629.issue23174@psf.upfronthosting.co.za>


Karl Richter added the comment:

EDIT 1: other examples, e.g.

    import os
    import shelve

    curdir = os.path.dirname(__file__)
    passwords = shelve.open(os.path.join(curdir, 'password_db'))

work, so there's need for usable error messages.

----------

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

From report at bugs.python.org  Tue Jan  6 01:58:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Jan 2015 00:58:51 +0000
Subject: [docs] [issue23174] shelve.open fails with error "anydbm.error: db
	type	could not be determined"
In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za>
Message-ID: <1420505931.13.0.768421732874.issue23174@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are opening a just-created empty file.  The db type of the file cannot, therefore, be determined.  Which is what the error message says. 

How would you suggest the error message be improved?

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

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

From report at bugs.python.org  Tue Jan  6 02:07:05 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Jan 2015 01:07:05 +0000
Subject: [docs] [issue23174] shelve.open fails with error "anydbm.error: db
	type	could not be determined"
In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za>
Message-ID: <1420506425.69.0.536734666429.issue23174@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sorry, I mean "an empty file with no recognized extension".  I doubt supplying a suffix is what you want, though, since you probably want shelve to pick the persistent backend on db creation in order to be portable.

----------

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

From report at bugs.python.org  Tue Jan  6 02:58:55 2015
From: report at bugs.python.org (Karl Richter)
Date: Tue, 06 Jan 2015 01:58:55 +0000
Subject: [docs] [issue23174] shelve.open fails with error "anydbm.error: db
	type	could not be determined"
In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za>
Message-ID: <1420509535.46.0.30738907687.issue23174@psf.upfronthosting.co.za>


Karl Richter added the comment:

Then, let the error message say "You are opening a just-created empty file.  The db type of the file cannot, therefore, be determined." which is much clearer than "anydbm.error: db type could not be determined" which sounds like a generic fallback error message in "an error occured"-style.

It seems to be necessary that the filename passed to `shelve.open` has a suffix which is not very intuitive for Linux users. It'd be great to have validation of the suffix and raise a `ValueError` with an error message like `"filename '%s' doesn't contain a suffix" % (filename,)` when it isn't supplied. If there's another issue regarding the fact that the file is "just-created" and empty, this is independent of the issue above.

----------

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

From report at bugs.python.org  Tue Jan  6 07:06:05 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 06 Jan 2015 06:06:05 +0000
Subject: [docs] [issue19548] 'codecs' module docs improvements
In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za>
Message-ID: <1420524364.85.0.193241859199.issue19548@psf.upfronthosting.co.za>


Martin Panter added the comment:

Adding patch v5, for the 3.4 branch. There is at least one reference that still needs fixing in the default branch that is not applicable to the 3.4 branch. Main changes from Nick?s patch:

* Removed sentence now redundant with introduction to open() and EncodedFile()
* Fixed wording to allow for missing surrogateescape_errors() etc
* Changed heading to clarify Codec objects are stateless
* Restored relaxation for StreamWriter writing to text stream
* New wording under ?Encodings and Unicode?
* Update cross references to new ?Error Handlers? section

----------
Added file: http://bugs.python.org/file37610/issue19548-codecs-doc.v5.py3.4.patch

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

From jmsachs at gmail.com  Mon Jan  5 22:06:51 2015
From: jmsachs at gmail.com (Jason Sachs)
Date: Mon, 5 Jan 2015 14:06:51 -0700
Subject: [docs] bug in argparse docs?
Message-ID: <CAOo6sOM7=ePmzZWSo87NScCKh+7a6dOk-3x2N+XZLFRK=PsEXg@mail.gmail.com>

In https://docs.python.org/2.7/library/argparse.html#action it says

  For more details, see Action.

but there is no link anywhere. Is there a link missing to
documentation on the Action class?

From vadmium+py at gmail.com  Tue Jan  6 07:05:30 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Tue, 06 Jan 2015 06:05:30 -0000
Subject: [docs] 'codecs' module docs improvements (issue 19548)
Message-ID: <20150106060530.20533.22215@psf.upfronthosting.co.za>

Addressing some of the comments in patch v5


https://bugs.python.org/review/19548/diff/13502/Doc/library/codecs.rst
File Doc/library/codecs.rst (right):

https://bugs.python.org/review/19548/diff/13502/Doc/library/codecs.rst#newcode211
Doc/library/codecs.rst:211: a text stream.
On 2014/12/31 10:53:25, vadmium wrote:
> Perhaps the last sentence is not needed, now that all these functions
are
> introduced as being for binary files.

Done.

https://bugs.python.org/review/19548/diff/13502/Doc/library/codecs.rst#newcode382
Doc/library/codecs.rst:382: The standard error handlers are implemented
in the following functions:
On 2014/12/31 10:53:25, vadmium wrote:
> This is just ?_Some_ standard error handlers?, since the surrogate
handlers are
> omitted.

Done.

https://bugs.python.org/review/19548/diff/13502/Doc/library/codecs.rst#newcode420
Doc/library/codecs.rst:420: Codec Objects
On 2014/12/31 10:53:25, vadmium wrote:
> On 2014/12/30 14:38:56, zuo wrote:
> > Still the relation between the `codec` term and the Codec
class/objects is not
> > clear IMHO.
> 
> Maybe changing the heading to ?Stateless Codec Objects? would help?

Done.

https://bugs.python.org/review/19548/diff/13502/Doc/library/codecs.rst#newcode625
Doc/library/codecs.rst:625: *stream* must be a file-like object open for
writing binary data.
On 2014/12/31 10:53:25, vadmium wrote:
> Did you mean to revert to ?binary data? here? Patch v3 changed the
wording here.

Restored new wording in my v5 patch for 3.4 branch

https://bugs.python.org/review/19548/diff/13502/Doc/library/codecs.rst#newcode829
Doc/library/codecs.rst:829: :term:`text encoding` and recreating the
On 2014/12/31 10:53:25, vadmium wrote:
> Transforming a string into a sequence of bytes is known as *encoding*,
and
> recreating the string from the sequence of bytes is known as
*decoding*.  There
> are different methods for how this transformation can be done.  (These
methods
> are also called :term:`text encodings <text encoding>`.)

Added my new wording in new patch

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

From jrvp at bordenrhodes.com  Tue Jan  6 08:07:43 2015
From: jrvp at bordenrhodes.com (Borden Rhodes)
Date: Tue, 6 Jan 2015 02:07:43 -0500
Subject: [docs] Ambiguity in python3.4 tutorial
Message-ID: <CABeHYocF1mu0nm7L80gkdV53Hut0owBX=m6MffzZQDFO6aSVbg@mail.gmail.com>

Good morning,

In https://docs.python.org/3/tutorial/introduction.html#lists, there
is an ambiguity. In section 3.1.3:
Paragraph 3 reads: "All slice operations return a new list containing
the requested elements."
Paragraph 7 reads: "Assignment to slices is also possible, and this
can even change the size of the list or clear it entirely."

For a new user like me, paragraph 3 suggests that assigning anything
to a slice would modify the new list, not the original list. Using the
example in the tutorial, if letters = [a, b, c, d, e, f, g], and
letters[2:5] returns the slice [c, d, e], then I would expect, under
paragraph 3, that letters[2:5] = [C, D, E] would yield letters[2:5] =
[C, D, E], since the array [C, D, E] would overwrite the new, 3
element array created by letters[2:5] which, under paragraph 3, is a
copy of a slice of letters[] and not letters[] itself.

As I said, I'm just starting out (but have experience in C++, Java &
PHP), so I haven't checked the language specification for
clarification. Perhaps the documentation could either remove the word
'all' in paragraph 3 so that it isn't as absolute or perhaps provide a
reference or explanation in paragraph 7 which explains why my
interpretation is incorrect.

Please let me know if I can provide any assistance or clarification.

With thanks,

Borden Rhodes

From report at bugs.python.org  Tue Jan  6 09:22:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Jan 2015 08:22:58 +0000
Subject: [docs] [issue23174] shelve.open fails with error "anydbm.error: db
	type	could not be determined"
In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za>
Message-ID: <1420532578.74.0.0816548372148.issue23174@psf.upfronthosting.co.za>


R. David Murray added the comment:

The problem is that this is not the only situation in which that error can be generated.  If someone passed in an "old" (and possibly non-empty) file with no extension, the same code path would get executed.

The shelve/anydbm API is database agnostic, so there is no way to know a-priori what the valid extensions are.  The whichdbm module (which anydbm uses) could provide this information in theory, but it doesn't currently, and if it did that would be a new API.

Your problem is that the shelve API is designed so that you either pass it the base name of an existing database, *or* you pass it the base name of a *non* existent database, which it then creates all the right files for (there may be more than one file).  The fact that you are passing it a new existing file is the problem, and I'm not sure the error message can be effectively improved to handle that particular mistaken use of the API without breaking the message for the places it is more meaningful.

The best I can think of is to add the filename to the error message and list all the extensions and (if there are any) the 'magic' type guesses that whichdbm tried, but as I said that would be a new feature and thus could only go into 3.5.

----------

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

From report at bugs.python.org  Tue Jan  6 11:22:53 2015
From: report at bugs.python.org (Karl Richter)
Date: Tue, 06 Jan 2015 10:22:53 +0000
Subject: [docs] [issue23174] shelve.open fails with error "anydbm.error: db
	type	could not be determined"
In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za>
Message-ID: <1420539773.04.0.190553571596.issue23174@psf.upfronthosting.co.za>


Karl Richter added the comment:

That's nice, thanks. Considering your last comment, some points

  * If the issue can't go into the error message, than the essence of the discussion here should go into the docs (in 0.5 to 1.5 sentences).
  * It'd be nice if it was clear from the error message that shelve or underlying modules check the extension in filename, i.e. do `anydbm.error: db type could not be determined by file extension '%s' in filename '%s'` rather than `anydbm.error: db type could not be determined`.

----------

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

From report at bugs.python.org  Tue Jan  6 15:38:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Jan 2015 14:38:55 +0000
Subject: [docs] [issue19548] 'codecs' module docs improvements
In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za>
Message-ID: <20150106143716.72575.26129@psf.io>


Roundup Robot added the comment:

New changeset 0646eee8296a by Nick Coghlan in branch '3.4':
Issue 19548: update codecs module documentation
https://hg.python.org/cpython/rev/0646eee8296a

New changeset 4d00d0109147 by Nick Coghlan in branch 'default':
Merge issue 19548 changes from 3.4
https://hg.python.org/cpython/rev/4d00d0109147

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

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

From report at bugs.python.org  Tue Jan  6 15:42:05 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Jan 2015 14:42:05 +0000
Subject: [docs] [issue19548] 'codecs' module docs improvements
In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za>
Message-ID: <1420555325.1.0.552679971089.issue19548@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks for the work on this folks, both Jan for the feedback, Martin for the writing, and everyone else for their comments.

I don't believe we addressed all of Jan's comments, but I'd like to request that any further comments be filed as separate issues, now that the larger restructure of the content is out of the way.

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

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

From berker.peksag at gmail.com  Tue Jan  6 17:27:57 2015
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Tue, 6 Jan 2015 18:27:57 +0200
Subject: [docs] bug in argparse docs?
In-Reply-To: <CAOo6sOM7=ePmzZWSo87NScCKh+7a6dOk-3x2N+XZLFRK=PsEXg@mail.gmail.com>
References: <CAOo6sOM7=ePmzZWSo87NScCKh+7a6dOk-3x2N+XZLFRK=PsEXg@mail.gmail.com>
Message-ID: <CAF4280KnTuf10Dbch_+wPRZSNjdVaNRZ2-_4qcrS4d00L5AbDA@mail.gmail.com>

On Mon, Jan 5, 2015 at 11:06 PM, Jason Sachs <jmsachs at gmail.com> wrote:
> In https://docs.python.org/2.7/library/argparse.html#action it says
>
>   For more details, see Action.
>
> but there is no link anywhere. Is there a link missing to
> documentation on the Action class?

Hi Jason,

Thanks for the report. Fixed in https://hg.python.org/cpython/rev/35b5ff543d4b

--Berker

From report at bugs.python.org  Tue Jan  6 17:36:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Jan 2015 16:36:41 +0000
Subject: [docs] [issue23174] shelve.open fails with error "anydbm.error: db
	type	could not be determined"
In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za>
Message-ID: <1420562201.84.0.864646994142.issue23174@psf.upfronthosting.co.za>


R. David Murray added the comment:

What is it you want the docs to say?

For your second point, yes, that is what I was saying would be an enhancement (the extension is a list of possible extensions that varies per-platform and per how python is built/installed).

----------

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

From report at bugs.python.org  Tue Jan  6 23:02:33 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 06 Jan 2015 22:02:33 +0000
Subject: [docs] [issue19548] 'codecs' module docs improvements
In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za>
Message-ID: <1420581753.48.0.254950849305.issue19548@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Nick. Here is a small followup patch for the default (3.5) branch to keep things consistent.

----------
Added file: http://bugs.python.org/file37618/default-branch-followup.patch

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

From report at bugs.python.org  Wed Jan  7 04:15:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Jan 2015 03:15:03 +0000
Subject: [docs] [issue19548] 'codecs' module docs improvements
In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za>
Message-ID: <20150107031458.8753.30685@psf.io>


Roundup Robot added the comment:

New changeset 20a5a56ce090 by Nick Coghlan in branch 'default':
Issue #19548: clean up merge issues in codecs docs
https://hg.python.org/cpython/rev/20a5a56ce090

----------

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

From report at bugs.python.org  Wed Jan  7 04:34:42 2015
From: report at bugs.python.org (Geoff Shannon)
Date: Wed, 07 Jan 2015 03:34:42 +0000
Subject: [docs] [issue22865] Allow pty.spawn to ignore data to copy
In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za>
Message-ID: <1420601682.59.0.619479422482.issue22865@psf.upfronthosting.co.za>


Geoff Shannon added the comment:

I tweaked the patch a bit to not include the parentheses since that seems to be the style here.

----------
Added file: http://bugs.python.org/file37620/pty.patch

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

From report at bugs.python.org  Wed Jan  7 05:59:02 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Jan 2015 04:59:02 +0000
Subject: [docs] [issue19548] 'codecs' module docs improvements
In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za>
Message-ID: <1420606742.49.0.344134282193.issue19548@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks for the follow-up patch Martin - I missed those when I did the merge forward from 3.4.

----------

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

From report at bugs.python.org  Wed Jan  7 07:59:33 2015
From: report at bugs.python.org (Mike Basca)
Date: Wed, 07 Jan 2015 06:59:33 +0000
Subject: [docs] [issue23156] Update tix install information in tkinter tix
	chapter of	doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1420613973.33.0.213458545355.issue23156@psf.upfronthosting.co.za>


Mike Basca added the comment:

Hi,  

I'm the original poster in the stack-exchange link.  Based on your responses,  It seems Ttk is the way to go if you're on Mac OSX 64-bit.

Thanks for your time and input.

Really appreciate it!

----------
nosy: +abaskm

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

From report at bugs.python.org  Wed Jan  7 09:43:49 2015
From: report at bugs.python.org (Al Sweigart)
Date: Wed, 07 Jan 2015 08:43:49 +0000
Subject: [docs] [issue23181] Unicode "code point" should be two words in
	documentation
Message-ID: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za>


New submission from Al Sweigart:

According to http://unicode.org/glossary/ "codepoint" is incorrect and should be changed to "code point".

----------
assignee: docs at python
components: Documentation
files: code_point_patch.diff
keywords: patch
messages: 233568
nosy: Al.Sweigart, docs at python
priority: normal
severity: normal
status: open
title: Unicode "code point" should be two words in documentation
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37623/code_point_patch.diff

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

From report at bugs.python.org  Wed Jan  7 09:53:19 2015
From: report at bugs.python.org (Chathuranga)
Date: Wed, 07 Jan 2015 08:53:19 +0000
Subject: [docs] [issue23183] timeit CLI best of 3: undocumented output format
Message-ID: <1420620799.47.0.00516438922368.issue23183@psf.upfronthosting.co.za>


New submission from Chathuranga:

easy

Following command is executed in terminal to use timeit module to measure time.

python -m timeit -v -n 3 "time.sleep(1)"

Output of the command:
raw times: 3 3 3
3 loops, best of 3: 1 sec per loop

The interpretation of this output is unclear, and no details available in the documentation.
https://docs.python.org/2/library/timeit.html#command-line-interface

----------
assignee: docs at python
components: Documentation
messages: 233570
nosy: docs at python, hachat
priority: normal
severity: normal
status: open
title: timeit CLI best of 3: undocumented output format
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan  7 20:15:48 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Jan 2015 19:15:48 +0000
Subject: [docs] [issue20487] Odd words in unittest.mock document.
In-Reply-To: <1391355507.86.0.158179018907.issue20487@psf.upfronthosting.co.za>
Message-ID: <20150107191544.22395.20277@psf.io>


Roundup Robot added the comment:

New changeset 230a1bfb0f59 by Berker Peksag in branch '3.4':
Issue #20487: Clarify meaning of "side effect" in the magic mock documentation.
https://hg.python.org/cpython/rev/230a1bfb0f59

New changeset 3cf91d2aeab3 by Berker Peksag in branch 'default':
Issue #20487: Clarify meaning of "side effect" in the magic mock documentation.
https://hg.python.org/cpython/rev/3cf91d2aeab3

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

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

From report at bugs.python.org  Wed Jan  7 20:19:01 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 07 Jan 2015 19:19:01 +0000
Subject: [docs] [issue20487] Odd words in unittest.mock document.
In-Reply-To: <1391355507.86.0.158179018907.issue20487@psf.upfronthosting.co.za>
Message-ID: <1420658341.19.0.123189698446.issue20487@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed. Thank you to both Andrew and Michael.

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

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

From report at bugs.python.org  Fri Jan  9 02:20:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Jan 2015 01:20:45 +0000
Subject: [docs] [issue23025] ssl.RAND_bytes docs should mention os.urandom
In-Reply-To: <1418235366.16.0.20927959194.issue23025@psf.upfronthosting.co.za>
Message-ID: <1420766444.04.0.986649089753.issue23025@psf.upfronthosting.co.za>


STINNER Victor added the comment:

To be clear: rand.diff looks good to me, go ahead.

----------

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

From report at bugs.python.org  Fri Jan  9 02:26:21 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 09 Jan 2015 01:26:21 +0000
Subject: [docs] [issue23200] Clarify max_length and flush() for zlib
	decompression
Message-ID: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za>


New submission from Martin Panter:

This simple patch documents that max_length has to be non-zero. The implementation actually uses zero as a special value to indicate max_length was not specified.

Also, I wonder what the point of the Decompressor.flush() method is. Reading the module code and zlib manual, it looks like it would return the same data as decompressor.decompress(decompressor.unconsumed_tail), except that it uses the Z_FINISH flag instead of Z_SYNC_FLUSH, so that zlib can optimize by assuming no more data is to be processed. Since unconsumed_tail is read-only and only relevant when using max_length, and flush does not support max_length, I wonder if the flush() method should be deprecated.

To further test this theory, I modified the test_zlib.py file so that all appropriate flush() calls are equivalent to this:

self.assertFalse(dco.flush())

and the tests all still pass.

BTW, it looks to me like zlib_Decompress_flush_impl() is setting avail_out too high (blessing unallocated memory) when the total length is more than half of UNIT_MAX, but I am not in a position to test this.

----------
assignee: docs at python
components: Documentation
files: max_length.patch
keywords: patch
messages: 233709
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Clarify max_length and flush() for zlib decompression
versions: Python 3.4
Added file: http://bugs.python.org/file37650/max_length.patch

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

From report at bugs.python.org  Fri Jan  9 03:08:57 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 09 Jan 2015 02:08:57 +0000
Subject: [docs] [issue23200] Clarify max_length and flush() for zlib
	decompression
In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za>
Message-ID: <1420769337.91.0.0894631942911.issue23200@psf.upfronthosting.co.za>


Martin Panter added the comment:

The processing of unconsumed_tail in flush() was introduced via Issue 16411. Before that I suspect flush() was assumed to only be called when max_length was not used.

The decompress() method changed from Z_NO_FLUSH to Z_SYNC_FLUSH in Feb 2001; see revision 01c2470eeb2e. I guess previously flush() was necessary to get all your data. The max_length parameter was added later in October that year; see Issue 403753 and revision 60e12f83d2d2.

----------

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

From report at bugs.python.org  Fri Jan  9 13:41:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 09 Jan 2015 12:41:07 +0000
Subject: [docs] =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0?=
 =?utf-8?q?and_readline=28=29_argument_names?=
In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za>
Message-ID: <1420807267.1.0.71821169783.issue17003@psf.upfronthosting.co.za>


Martin Panter added the comment:

Is there anything left for this bug or could it be closed? I can confirm my v3.4.2 docs say ?size? instead of ?n? :)

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

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

From report at bugs.python.org  Fri Jan  9 16:03:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Jan 2015 15:03:32 +0000
Subject: [docs] =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0?=
 =?utf-8?q?and_readline=28=29_argument_names?=
In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za>
Message-ID: <1420815812.33.0.676476315361.issue17003@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

readlines() parameter name is not unified still (it can be "hint", "size", "sizehint"). There is no obvious winner.

----------

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

From report at bugs.python.org  Fri Jan  9 18:32:38 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 09 Jan 2015 17:32:38 +0000
Subject: [docs] [issue23210] clarify "virtual sequence" and range docs
Message-ID: <1420824758.29.0.716744408314.issue23210@psf.upfronthosting.co.za>


New submission from Ethan Furman:

The help() function explains range as being a "virtual sequence", but that phrase cannot be found anywhere in the docs.

Suggestion is to insert a phrase below:

>> The advantage of the range type over a regular list or tuple is
>> that a range object

 is a virtual sequence and so

>> will always take the same (small) amount of memory [...]

Bonus points for adding a glossary entry.  :)

----------
assignee: docs at python
components: Documentation
messages: 233771
nosy: docs at python, ethan.furman
priority: low
severity: normal
stage: needs patch
status: open
title: clarify "virtual sequence" and range docs
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan  9 18:51:21 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 09 Jan 2015 17:51:21 +0000
Subject: [docs] [issue23210] clarify "virtual sequence" and range docs
In-Reply-To: <1420824758.29.0.716744408314.issue23210@psf.upfronthosting.co.za>
Message-ID: <1420825881.1.0.261398198914.issue23210@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Update:  per Guido, we need to drop the word "virtual" from the help() for range.

----------

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

From report at bugs.python.org  Fri Jan  9 18:58:51 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 09 Jan 2015 17:58:51 +0000
Subject: [docs] [issue23210] clarify "virtual sequence" and range docs
In-Reply-To: <1420824758.29.0.716744408314.issue23210@psf.upfronthosting.co.za>
Message-ID: <1420826331.69.0.510603297576.issue23210@psf.upfronthosting.co.za>


Ethan Furman added the comment:

On 01/09/2015 09:39 AM, Guido van Rossum wrote:
> Please don't add this to the glossary and don't start using "virtual" (it is
> my favorite example of terminology gone wrong in C++ as well as in colloquial
> language). The terminology "virtual sequence" is only used once, and probably
> a holdover from the Python 2 times when the idea was to describe the difference
> between xrange and range. Just drop the word "virtual" please!

I think the word has an important implication (low memory usage) and keeping it (and adding it to the range docs) would be useful to somebody who was searching for such a thing and unfamiliar with how range was constructed... on the other hand, generators are very similar (although not full Sequences) and we don't use the word virtual with them...

----------

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

From report at bugs.python.org  Fri Jan  9 19:39:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Jan 2015 18:39:59 +0000
Subject: [docs] [issue23210] clarify "virtual sequence" and range docs
In-Reply-To: <1420824758.29.0.716744408314.issue23210@psf.upfronthosting.co.za>
Message-ID: <1420828798.96.0.94484061602.issue23210@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree with Guido.  Virtual is an abused word and I can't imagine anyone searching on it unless they saw it used somewhere in the first place.  Range is a sequence, and the help docs are just a reminder.  The Range docs clearly explain the advantages of the range type.

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

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

From report at bugs.python.org  Fri Jan  9 20:07:16 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 09 Jan 2015 19:07:16 +0000
Subject: [docs] [issue23210] remove the word "virtual" from help(range)
In-Reply-To: <1420824758.29.0.716744408314.issue23210@psf.upfronthosting.co.za>
Message-ID: <1420830436.85.0.601266392337.issue23210@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Others have chimed in for removal of the word "virtual", with the Best In Class comment going to Guido for:

> To me it is a poisonous buzzword that we're better without.
> It has virtually no semantics left. :-)

----------
assignee: docs at python -> 
components: +Interpreter Core -Documentation
nosy: +pitrou
title: clarify "virtual sequence" and range docs -> remove the word "virtual" from help(range)

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

From report at bugs.python.org  Fri Jan  9 23:40:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Jan 2015 22:40:47 +0000
Subject: [docs] [issue23210] remove the word "virtual" from help(range)
In-Reply-To: <1420824758.29.0.716744408314.issue23210@psf.upfronthosting.co.za>
Message-ID: <20150109224044.8753.28213@psf.io>


Roundup Robot added the comment:

New changeset 79f33147949b by Benjamin Peterson in branch '3.4':
remove buzzword (closes #23210)
https://hg.python.org/cpython/rev/79f33147949b

New changeset 154ae3af0317 by Benjamin Peterson in branch 'default':
merge 3.4 (#23210)
https://hg.python.org/cpython/rev/154ae3af0317

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

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

From report at bugs.python.org  Sat Jan 10 05:26:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Jan 2015 04:26:53 +0000
Subject: [docs] [issue5811] io.BufferedReader.peek(): Documentation differs
	from	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1420864013.61.0.577338103181.issue5811@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a simple documentation patch to guarantee that at least one byte is normally returned. This would make the method much more useful, and compatible with the BZ2File and LZMAFile interfaces, allowing them to use BufferedReader, as I propose to do in Issue 15955.

Even if nobody is interested in Torsten?s patch to limit the return length, I suggest my patch be considered :)

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
Added file: http://bugs.python.org/file37661/peek-one-byte.patch

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

From report at bugs.python.org  Sat Jan 10 07:23:42 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Jan 2015 06:23:42 +0000
Subject: [docs] [issue23144] html.parser.HTMLParser: setting
	'convert_charrefs =	True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1420871022.46.0.0157024641681.issue23144@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> ezio.melotti

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

From report at bugs.python.org  Sat Jan 10 08:44:26 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Jan 2015 07:44:26 +0000
Subject: [docs] [issue20699] Behavior of ZipFile with file-like object
	and	BufferedWriter.
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1420875865.43.0.821968770474.issue20699@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think the simplest thing to do here would be to update the documentation to match the usage. This patch does so, saying that all write() methods, as well as the BytesIO() constructor, have to accept bytes-like objects. It also expands some tests to verify this, and fixes a resulting bug in _pyio.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +patch
nosy: +docs at python
Added file: http://bugs.python.org/file37662/bytes-like-param.patch

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

From report at bugs.python.org  Sat Jan 10 10:34:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Jan 2015 09:34:53 +0000
Subject: [docs] [issue20699] Behavior of ZipFile with file-like object
	and	BufferedWriter.
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1420882493.24.0.401920454588.issue20699@psf.upfronthosting.co.za>


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


----------
nosy: +serhiy.storchaka
stage:  -> patch review
versions: +Python 3.5

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

From report at bugs.python.org  Sun Jan 11 03:04:30 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Sun, 11 Jan 2015 02:04:30 +0000
Subject: [docs] [issue11691] sqlite3 Cursor.description doesn't set type_code
In-Reply-To: <1301199375.2.0.455501522423.issue11691@psf.upfronthosting.co.za>
Message-ID: <1420941870.77.0.247727004932.issue11691@psf.upfronthosting.co.za>


Changes by Gerhard H?ring <gh at ghaering.de>:


----------
assignee: docs at python -> ghaering

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

From report at bugs.python.org  Sun Jan 11 07:27:33 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Jan 2015 06:27:33 +0000
Subject: [docs] [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1420957652.66.0.660027306406.issue4395@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch that documents the default object.__ne__() implementation. It also documents the subclass priority rules for the reflected comparison methods, which is raised in Issue 22052.

I have made some more tests to verify the relationships exists from __ne__ to __eq__, but no other relationships exist for the other methods. I will include it in my patch in Issue 21408 to avoid the patches conflicting with each other.

----------
keywords: +patch
nosy: +vadmium
Added file: http://bugs.python.org/file37671/default-ne-reflected-priority.patch

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

From report at bugs.python.org  Sun Jan 11 07:36:23 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Jan 2015 06:36:23 +0000
Subject: [docs] [issue22052] Comparison operators called in reverse order
	for	subclasses with no override.
In-Reply-To: <1406149410.09.0.756154064568.issue22052@psf.upfronthosting.co.za>
Message-ID: <1420958183.31.0.086406781778.issue22052@psf.upfronthosting.co.za>


Martin Panter added the comment:

I have included some rules about the priority for calling reflected operator methods in my patch to Issue 4395

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

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

From report at bugs.python.org  Sun Jan 11 07:39:37 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 11 Jan 2015 06:39:37 +0000
Subject: [docs] [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1420958377.9.0.751234624393.issue4395@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

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

From report at bugs.python.org  Sun Jan 11 07:39:54 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 11 Jan 2015 06:39:54 +0000
Subject: [docs] [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1420958394.7.0.658395988486.issue4395@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

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

From report at bugs.python.org  Sun Jan 11 08:05:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Jan 2015 07:05:16 +0000
Subject: [docs] [issue23221] "a(n) the", "the a(n)" typos
In-Reply-To: <1420940360.26.0.834732182943.issue23221@psf.upfronthosting.co.za>
Message-ID: <1420959916.01.0.855792136602.issue23221@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
stage:  -> needs patch

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

From report at bugs.python.org  Sun Jan 11 14:04:00 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Jan 2015 13:04:00 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <20150111130343.22407.47497@psf.io>


Roundup Robot added the comment:

New changeset d81cabb39de3 by Mark Dickinson in branch '2.7':
Issue #21902: Replace incorrect 'hyperbolic arc sine' (etc.) with 'inverse hyperbolic sine' (etc.).  Remove meaningless reference to radians.
https://hg.python.org/cpython/rev/d81cabb39de3

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

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

From report at bugs.python.org  Sun Jan 11 14:23:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Jan 2015 13:23:42 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <20150111132335.22397.11355@psf.io>


Roundup Robot added the comment:

New changeset 5edfc6c929f9 by Mark Dickinson in branch '3.4':
Issue #21902: Replace incorrect 'hyperbolic arc sine' (etc.) with 'inverse hyperbolic sine' (etc.).  Remove meaningless reference to radians.
https://hg.python.org/cpython/rev/5edfc6c929f9

----------

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

From report at bugs.python.org  Sun Jan 11 14:23:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Jan 2015 13:23:42 +0000
Subject: [docs] [issue21092] json serializer implicitly stringifies
	non-string keys
In-Reply-To: <1396058532.4.0.747084200104.issue21092@psf.upfronthosting.co.za>
Message-ID: <20150111132335.22397.70343@psf.io>


Roundup Robot added the comment:

New changeset 36099a05d76a by Mark Dickinson in branch 'default':
Issue #21092: Merge from 3.4.
https://hg.python.org/cpython/rev/36099a05d76a

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

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

From report at bugs.python.org  Sun Jan 11 14:28:15 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 11 Jan 2015 13:28:15 +0000
Subject: [docs] [issue21092] json serializer implicitly stringifies
	non-string keys
In-Reply-To: <1396058532.4.0.747084200104.issue21092@psf.upfronthosting.co.za>
Message-ID: <1420982895.49.0.683421031184.issue21092@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Sorry; that last commit message should have been for #21902.

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

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

From report at bugs.python.org  Sun Jan 11 14:28:52 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 11 Jan 2015 13:28:52 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1420982932.59.0.670720136543.issue21902@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Roundup message copied from #21902 (bad issue number):

New changeset 36099a05d76a by Mark Dickinson in branch 'default':
Issue #21092: Merge from 3.4.
https://hg.python.org/cpython/rev/36099a05d76a

----------

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

From report at bugs.python.org  Sun Jan 11 14:29:16 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 11 Jan 2015 13:29:16 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1420982956.51.0.375162187222.issue21902@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Closing as fixed.

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

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

From report at bugs.python.org  Sun Jan 11 15:07:10 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Jan 2015 14:07:10 +0000
Subject: [docs] [issue22952] multiprocessing doc introduction not in
	affirmative tone
In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>
Message-ID: <20150111140706.8767.17813@psf.io>


Roundup Robot added the comment:

New changeset a9a9c71f8e15 by Antoine Pitrou in branch '3.4':
Issue #22952: improve multiprocessing doc introduction and defer notes until appropriate.
https://hg.python.org/cpython/rev/a9a9c71f8e15

New changeset a65c23ea5f9e by Antoine Pitrou in branch 'default':
Issue #22952: improve multiprocessing doc introduction and defer notes until appropriate.
https://hg.python.org/cpython/rev/a65c23ea5f9e

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

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

From report at bugs.python.org  Sun Jan 11 15:09:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Jan 2015 14:09:38 +0000
Subject: [docs] [issue22952] multiprocessing doc introduction not in
	affirmative tone
In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>
Message-ID: <20150111140935.125884.69122@psf.io>


Roundup Robot added the comment:

New changeset e7d03a33e675 by Antoine Pitrou in branch '2.7':
Issue #22952: improve multiprocessing doc introduction and defer notes until appropriate.
https://hg.python.org/cpython/rev/e7d03a33e675

----------

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

From report at bugs.python.org  Sun Jan 11 15:10:17 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Jan 2015 14:10:17 +0000
Subject: [docs] [issue22952] multiprocessing doc introduction not in
	affirmative tone
In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>
Message-ID: <1420985416.96.0.314051714378.issue22952@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I've committed your patches, Davin. Thank you for contributing!

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

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

From report at bugs.python.org  Sun Jan 11 15:11:09 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Jan 2015 14:11:09 +0000
Subject: [docs] [issue23100] multiprocessing doc organization impedes
	understanding
In-Reply-To: <1419292691.51.0.0335324108877.issue23100@psf.upfronthosting.co.za>
Message-ID: <1420985469.44.0.279632375791.issue23100@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> I am happy to provide proposed patches but first can someone please clarify for me whether I should have those patches depend upon the patches from Issue 22952?

This question is now moot :)

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

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

From report at bugs.python.org  Sun Jan 11 17:17:03 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Jan 2015 16:17:03 +0000
Subject: [docs] [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1420993023.66.0.585419731556.issue4395@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jan 11 17:48:16 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Jan 2015 16:48:16 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1420994896.52.0.0476642565599.issue21902@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan 12 10:54:38 2015
From: report at bugs.python.org (Karan Goel)
Date: Mon, 12 Jan 2015 09:54:38 +0000
Subject: [docs] [issue23221] "a(n) the", "the a(n)" typos
In-Reply-To: <1420940360.26.0.834732182943.issue23221@psf.upfronthosting.co.za>
Message-ID: <1421056478.84.0.900209768363.issue23221@psf.upfronthosting.co.za>


Karan Goel added the comment:

Hey I'll be working on this and submitting a patch.

----------
nosy: +karan

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

From report at bugs.python.org  Mon Jan 12 11:10:52 2015
From: report at bugs.python.org (Karan Goel)
Date: Mon, 12 Jan 2015 10:10:52 +0000
Subject: [docs] [issue23221] "a(n) the", "the a(n)" typos
In-Reply-To: <1420940360.26.0.834732182943.issue23221@psf.upfronthosting.co.za>
Message-ID: <1421057452.58.0.637690042366.issue23221@psf.upfronthosting.co.za>


Karan Goel added the comment:

There we go. I fixed all the reported typos using the best of my knowledge.

----------
keywords: +patch
Added file: http://bugs.python.org/file37680/issue23221.patch

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

From report at bugs.python.org  Mon Jan 12 23:40:48 2015
From: report at bugs.python.org (Andrew Barnert)
Date: Mon, 12 Jan 2015 22:40:48 +0000
Subject: [docs] [issue23226] Add float linspace recipe to docs
Message-ID: <1421102448.57.0.289351503451.issue23226@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

In a recent thread on python-ideas (https://mail.python.org/pipermail/python-ideas/2015-January/030817.html), it was concluded that Python should not have a range-like type for floats in the stdlib, but there should be some simple discussion of the alternatives in the docs.

The attached diff describes the issues, demonstrates the simplest reasonable algorithm, and links to a recipe on ActiveState (which builds the same algorithm into a lazy sequence, and links to other recipes with different alternatives).

----------
assignee: docs at python
components: Documentation
files: stdtypes.rst.diff
keywords: patch
messages: 233893
nosy: abarnert, docs at python
priority: normal
severity: normal
status: open
title: Add float linspace recipe to docs
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37684/stdtypes.rst.diff

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

From report at bugs.python.org  Tue Jan 13 00:22:33 2015
From: report at bugs.python.org (Andrew Barnert)
Date: Mon, 12 Jan 2015 23:22:33 +0000
Subject: [docs] [issue23226] Add float linspace recipe to docs
In-Reply-To: <1421102448.57.0.289351503451.issue23226@psf.upfronthosting.co.za>
Message-ID: <1421104953.94.0.322199711758.issue23226@psf.upfronthosting.co.za>


Andrew Barnert added the comment:

As suggested by the review: removing unnecessary parenthetical, changing "ulp" to "digit", and fixing the recipe link.

----------
Added file: http://bugs.python.org/file37685/stdtypes.rst.diff

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

From report at bugs.python.org  Tue Jan 13 08:35:46 2015
From: report at bugs.python.org (Stephen Drake)
Date: Tue, 13 Jan 2015 07:35:46 +0000
Subject: [docs] [issue23227] Generator's finally block not run if close()
	called	before first iteration
Message-ID: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za>


New submission from Stephen Drake:

If a generator has its close() method called before any items are requested from it, a finally block in the generator function will not be executed.

I encountered this when wrapping an open file to alter the result of iterating over it.  Using a generator function with a try/finally block seemed like a simple way of acheiving this.  Here's an example that logs each line as it's read:

def logged_lines(f):
    try:
        for line in f:
            logging.warning(line.strip())
            yield line
    finally:
        logging.warning('closing')
        f.close()

If the generator is created and closed immediately, the underlying file-like object is left open:
>>> f = urlopen('https://docs.python.org/')
>>> lines = logged_lines(f)
>>> lines.close()
>>> f.closed
False

But once the first item is requested from the generator, close() will trigger cleanup:
>>> lines = logged_lines(f)
>>> next(lines)
WARNING:root:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
'<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"\n'
>>> lines.close()
WARNING:root:closing
>>> f.closed
True

Having read the documentation for yield expressions, I don't believe this behaviour to be non-conformant - but it still seems like a bit of a gotcha to me.  Should this usage be warned against?

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 233903
nosy: docs at python, sjdrake
priority: normal
severity: normal
status: open
title: Generator's finally block not run if close() called before first iteration
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Jan 13 14:12:06 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Jan 2015 13:12:06 +0000
Subject: [docs] [issue23227] Generator's finally block not run if close()
	called	before first iteration
In-Reply-To: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za>
Message-ID: <1421154726.43.0.218783925336.issue23227@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan 13 15:20:46 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Jan 2015 14:20:46 +0000
Subject: [docs] [issue23221] "a(n) the", "the a(n)" typos
In-Reply-To: <1420940360.26.0.834732182943.issue23221@psf.upfronthosting.co.za>
Message-ID: <20150113142038.125908.2355@psf.io>


Roundup Robot added the comment:

New changeset b168c41f2e3f by Benjamin Peterson in branch '3.4':
fix instances of consecutive articles (closes #23221)
https://hg.python.org/cpython/rev/b168c41f2e3f

New changeset 6a19e37ce94d by Benjamin Peterson in branch '2.7':
fix instances of consecutive articles (closes #23221)
https://hg.python.org/cpython/rev/6a19e37ce94d

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

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

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

From report at bugs.python.org  Tue Jan 13 16:04:27 2015
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 13 Jan 2015 15:04:27 +0000
Subject: [docs] [issue23232] 'codecs' module functionality + its docs --
	concerning	custom codecs, especially non-string ones
Message-ID: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski:

To some extent, this issue is a follow-up of Issue 20132. It concerns some parts of functionality + documentation of the 'codecs' module related to registering custom codecs, especially non-string ones (i.e., codecs that encode/decode between arbitrary types, not necessarily the str and bytes types).

A few fragments of documented behaviour and/or documentation itself bother me:


0. Ad "7.2.1. Codec Base Classes"

"Each codec has to define four interfaces to make it usable as codec in Python: stateless encoder, stateless decoder, stream reader and stream writer. The stream reader and writers typically reuse the stateless encoder/decoder to implement the file protocols. Codec authors also need to define how the codec will handle encoding and decoding errors."

IMHO it is still unclear:

a) what is the relation between codecs in this meaning and CodecInfo objects? (especially: CodecInfo contains information about six interfaces, not four)

b) How codec authors define "how the codec will handle encoding and decoding errors"? What is relation between this and error handling schemes (defined as generic, not per-codec ones) documented below? 


1. Ad "7.2.1.1. Error Handlers" and "codecs.strict_errors(exception)"

"'strict' 	Raise UnicodeError (or a subclass); this is the default. Implemented in strict_errors()."

"codecs.strict_errors(exception)
Implements the 'strict' error handling: each encoding or decoding error raises a UnicodeError."

Is it true that always it is a UnicodeError or its subclass and not just ValueError or its subclass? (as it is described in other fragments of the module documentation).

Please note, that 'strict' is documented as a universal (and not e.g. text-encoding-only) error handling scheme. So, what about non-string codecs?


2. Ad "codecs.register_error(name, error_handler)"

"For encoding, error_handler will be called with a UnicodeEncodeError instance..." "Decoding and translating works similarly, except UnicodeDecodeError or UnicodeTranslateError will be passed..."

Again: what about non-string codecs? UnicodeError subclasses do not seem to be appropriate for them.


3. It would be nice to address the Zoinkity's concerns from the Issue 20132 (partially related to the above points):

"""
One glaring omission is any information about multibyte codecs--the class, its methods, and how to even define one.  

Also, the primary use for codecs.register would be to append a single codec to the lookup registry.  Simple usage of the method only provides lookup for the provided codecs and will not include regularly-accessible ones such as "utf-8".  It would be enormously helpful to provide an example of proper, safe usage.
"""

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 233940
nosy: docs at python, zuo
priority: normal
severity: normal
status: open
title: 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jan 13 16:08:39 2015
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 13 Jan 2015 15:08:39 +0000
Subject: [docs] [issue23232] 'codecs' module functionality + its docs --
	concerning	custom codecs, especially non-string ones
In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za>
Message-ID: <1421161719.84.0.346276052277.issue23232@psf.upfronthosting.co.za>


Jan Kaliszewski added the comment:

Sorry,

s/Issue 20132/Issue 19548/g

Issue 20132 is also related somehow, but here I ment that this is a follow-up of Issue 19548; and Zoinkity's concerns I cited are also from Issue 19548, and not from 20132.

----------

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

From report at bugs.python.org  Tue Jan 13 21:54:38 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 13 Jan 2015 20:54:38 +0000
Subject: [docs] [issue23232] 'codecs' module functionality + its docs --
	concerning	custom codecs, especially non-string ones
In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za>
Message-ID: <1421182478.83.0.836643155193.issue23232@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan 13 22:35:39 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Jan 2015 21:35:39 +0000
Subject: [docs] [issue23232] 'codecs' module functionality + its docs --
	concerning	custom codecs, especially non-string ones
In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za>
Message-ID: <1421184939.13.0.0329747475455.issue23232@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ncoghlan

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

From report at bugs.python.org  Wed Jan 14 00:37:12 2015
From: report at bugs.python.org (Al Sweigart)
Date: Tue, 13 Jan 2015 23:37:12 +0000
Subject: [docs] [issue23181] Unicode "code point" should be two words in
	documentation
In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za>
Message-ID: <1421192232.78.0.676573222605.issue23181@psf.upfronthosting.co.za>


Changes by Al Sweigart <asweigart at gmail.com>:


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

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

From report at bugs.python.org  Wed Jan 14 01:53:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 14 Jan 2015 00:53:04 +0000
Subject: [docs] [issue12160] codecs doc: what is StreamCodec?
In-Reply-To: <1306166137.72.0.066960808058.issue12160@psf.upfronthosting.co.za>
Message-ID: <1421196784.64.0.792416594198.issue12160@psf.upfronthosting.co.za>


Martin Panter added the comment:

This patch looks simple and uncontroversial. I think it could be merged.

----------
nosy: +vadmium
versions: +Python 3.4

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

From report at bugs.python.org  Wed Jan 14 06:48:10 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 14 Jan 2015 05:48:10 +0000
Subject: [docs] [issue23226] Add float linspace recipe to docs
In-Reply-To: <1421102448.57.0.289351503451.issue23226@psf.upfronthosting.co.za>
Message-ID: <1421214490.39.0.744525725272.issue23226@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This is too much.  Try for a brief reference.  This section of the docs is primarily about how range() works.  Linspace() is at best a tangential discussion and shouldn't interfere with the usability of range() docs (a tool we actually have and that is in common use).

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

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

From report at bugs.python.org  Wed Jan 14 07:45:55 2015
From: report at bugs.python.org (Andrew Barnert)
Date: Wed, 14 Jan 2015 06:45:55 +0000
Subject: [docs] [issue23226] Add float linspace recipe to docs
In-Reply-To: <1421102448.57.0.289351503451.issue23226@psf.upfronthosting.co.za>
Message-ID: <1421217955.66.0.420502294095.issue23226@psf.upfronthosting.co.za>


Andrew Barnert added the comment:

So something like the first version below? Or should even the example be inline, as in the second version below? (Apologies if the formatting gets screwed up pasting from docs to bugs.)

---

Range objects are inappropriate for non-integral types, especially inexact types such as :class:`float`.  In most cases, for such types, it is better to specify a count of numbers or intervals instead of a step size.  For example:

   >>> start, stop, num = 0, 10, 11
   >>> step = (stop-start)/(num-1)
   >>> [start + i*step for i in range(num)]
   [0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0]

.. seealso::

   * `linspace recipe <http://code.activestate.com/recipes/579000/>`_
     for an example lazy sequence built on this algorithm, and links
     to alternatives.

---

Range objects are inappropriate for non-integral types, especially inexact types such as :class:`float`.  In most cases, it is better to specify a count of numbers or intervals instead of a step size, as in `[start + i*(stop-start)/(num-1) for i in range(num)]`.

.. seealso::

   * `linspace recipe <http://code.activestate.com/recipes/579000/>`_
     for an example lazy sequence built on this algorithm, and links
     to alternatives.

----------

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

From padilla.sirera at gmail.com  Tue Jan  6 23:11:31 2015
From: padilla.sirera at gmail.com (=?utf-8?Q?Nat=C3=A0lia_Padilla_Sirera?=)
Date: Tue, 6 Jan 2015 23:11:31 +0100
Subject: [docs] bug
Message-ID: <64DF6A98-D6B4-411D-A282-31A0DA076736@gmail.com>

Hi,

I have done a script that contains

with open (?file.txt?, ?w?) as fh: fh.write(?blabla1?)

afterwards I do,

with open (?FILE.txt?, ?w?) as fh: fh.write(?blabla2?)

the result is a file called ?file.txt? that contains blabla2

I think that the name of the file is not case sensitive and I think that it should be.

Thanks a lot,

Nat?lia

From thia at wyrod.ca  Fri Jan  9 23:01:45 2015
From: thia at wyrod.ca (Thia Wyrod)
Date: Fri, 09 Jan 2015 15:01:45 -0700
Subject: [docs] hashlib.pbkdf2_hmac parameter names are incorrect
Message-ID: <54B04FC9.5040602@wyrod.ca>

The documentation lists the function signature as follows:
hashlib.pbkdf2_hmac(name, password, salt, rounds, dklen=None)

Some parameter names are wrong. The correct signature is:
hashlib.pbkdf2_hmac(hash_name, password, salt, iterations, dklen=None)

--
Thia

From morro157 at umn.edu  Sat Jan 10 02:31:06 2015
From: morro157 at umn.edu (Jonathan Morrow)
Date: Fri, 9 Jan 2015 19:31:06 -0600
Subject: [docs] Documentation Clarification
Message-ID: <CADmp-PZ9qTTE0Lc5ftAOt8s6O05L4YNeFDieGWgG-7P_7sAPVQ@mail.gmail.com>

For Python 3.4.2 Documentation, in Standard Library >> 6. Test Processing
Services >> 6.1 string.

In section 6.1.3.1 ("Format Specification Mini-Language"), I would like to
suggest that it is clearly pointed out at the beginning that *all uses of
the *format_spec* must be prefaced by a colon *":" *in order to be
grammatically correct*. Note that this section is most relevant to people
needing quick references, and as such will likely be read independently of
the containing section 6.1.3.

J.M.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150109/6a3de386/attachment-0001.html>

From rbattistin at apf.it  Sun Jan 11 12:13:03 2015
From: rbattistin at apf.it (Renato Battistin)
Date: Sun, 11 Jan 2015 12:13:03 +0100
Subject: [docs] Setting a python cgi-bin web service - 2
Message-ID: <6b133d32c5ab9d2f2ecbab9b62f9b5ab@apf.it>


Hello (again),

I am sorry, was my mistake!

I used the 3.3 docs instead of the 2.7 ones

Regards

Renato

===============

PREVIOUS MESSAGE:

Hello,

I don't known if it is a bug, but the following script example at 
https://docs.python.org/3.3/howto/webservers.html created me some 
problems during the setting of an apache2 cgi-bin python script service:


--------------------
#!/usr/bin/env python
# -*- coding: UTF-8 -*-

# enable debugging
import cgitb
cgitb.enable()

print("Content-Type: text/plain;charset=utf-8")
print()

print("Hello World!")
----------------

I solved the problem changing the above script to:

--------------------
#!/usr/bin/env python
# -*- coding: UTF-8 -*-

# enable debugging
import cgitb
cgitb.enable()

print "Content-Type: text/plain;charset=utf-8"
print

print "Hello World!"
----------------

I used Python 2.7

Regards

Renato Battistin
FERMO POSTA
I-31041 CORNUDA TV
ITALY


From rbattistin at apf.it  Sun Jan 11 12:06:49 2015
From: rbattistin at apf.it (Renato Battistin)
Date: Sun, 11 Jan 2015 12:06:49 +0100
Subject: [docs] Setting a python cgi-bin web service
Message-ID: <50f9672d4d1daf508c31893b82854452@apf.it>


Hello,

I don't known if it is a bug, but the following script example at 
https://docs.python.org/3.3/howto/webservers.html created me some 
problems during the setting of an apache2 cgi-bin python script service:


--------------------
#!/usr/bin/env python
# -*- coding: UTF-8 -*-

# enable debugging
import cgitb
cgitb.enable()

print("Content-Type: text/plain;charset=utf-8")
print()

print("Hello World!")
----------------

I solved the problem changing the above script to:

--------------------
#!/usr/bin/env python
# -*- coding: UTF-8 -*-

# enable debugging
import cgitb
cgitb.enable()

print "Content-Type: text/plain;charset=utf-8"
print

print "Hello World!"
----------------

I used Python 2.7

Regards

Renato Battistin
FERMO POSTA
I-31041 CORNUDA TV
ITALY

From kasturigarg at gmail.com  Mon Jan 12 10:28:41 2015
From: kasturigarg at gmail.com (pankaj garg)
Date: Mon, 12 Jan 2015 14:58:41 +0530
Subject: [docs] list.insert(i,x) behavior
Message-ID: <CA+YgdAcQWgECz-XZLUmgJqd=2TT8r8KF3yvvoFOCKMvPdwrJqw@mail.gmail.com>

Hi Sir/Madam

I am trying following stuff with lists.

*Line 1* >>> a = [1,2,3,4,5]
*Line 2* >>> a.insert(5,6)
*Line 3* >>> a
*Line 5*        [1,2,3,4,5,6]
*Line 6* >>> a.insert(9,9)
*Line 7* >>> a
*Line 8*        [1,2,3,4,5,6,9]

Output shouldn't be [1,2,3,4,5,6,0,0,0,9] as index specified is *index = 9*

I checked this on *Python 3.4.2*

Regards
Pankaj Garg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150112/ed6671b4/attachment.html>

From nntheprince866 at gmail.com  Mon Jan 12 23:56:14 2015
From: nntheprince866 at gmail.com (Navin Senguttuvan)
Date: Mon, 12 Jan 2015 16:56:14 -0600
Subject: [docs] Bug in 3.1.2
Message-ID: <CAMLv3x=YC_yU52a6JeW-yWjNPzbOrYkO7B4ErjT+Asv+TNzN1Q@mail.gmail.com>

Hi ,
In the section 3.1.2 (strings) , string slice example (the last but one
example code in the section) , shouldn't the second output be
"Pytpy"

Thanks,
Navin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150112/dbbab913/attachment.html>

From ghost.adh at gmail.com  Tue Jan 13 00:02:02 2015
From: ghost.adh at gmail.com (ghost.adh at gmail.com)
Date: Mon, 12 Jan 2015 23:02:02 -0000
Subject: [docs] Add float linspace recipe to docs (issue 23226)
Message-ID: <20150112230202.19879.30885@psf.upfronthosting.co.za>


http://bugs.python.org/review/23226/diff/13605/Doc/library/stdtypes.rst
File Doc/library/stdtypes.rst (right):

http://bugs.python.org/review/23226/diff/13605/Doc/library/stdtypes.rst#newcode1339
Doc/library/stdtypes.rst:1339: (e.g., by multiplying instead of
repeating addition), to avoid
It's not particularly clear what is responsible for accumulated rounding
errors: multiplication or repeated addition. Perhaps the whole
explanation in the brackets could be removed?

http://bugs.python.org/review/23226/diff/13605/Doc/library/stdtypes.rst#newcode1346
Doc/library/stdtypes.rst:1346: values, and potentially being off by 1
ulp on the :data:`stop` value)
sorry, what's `ulp'?

http://bugs.python.org/review/23226/diff/13605/Doc/library/stdtypes.rst#newcode1356
Doc/library/stdtypes.rst:1356: * `linspace recipe
<http://code.activestate.com/recipes/576694/>`_
Link leads to OrderedSet recipe

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

From abarnert at yahoo.com  Tue Jan 13 00:21:18 2015
From: abarnert at yahoo.com (Andrew Barnert)
Date: Mon, 12 Jan 2015 15:21:18 -0800
Subject: [docs] Add float linspace recipe to docs (issue 23226)
In-Reply-To: <20150112230202.19879.30885@psf.upfronthosting.co.za>
References: <20150112230202.19879.30885@psf.upfronthosting.co.za>
Message-ID: <B7B1A896-3D92-4647-B4B4-0CC46E955631@yahoo.com>

On Jan 12, 2015, at 15:02, ghost.adh at gmail.com wrote:

Thanks for the quick review. Comments inline.
> 
> http://bugs.python.org/review/23226/diff/13605/Doc/library/stdtypes.rst
> File Doc/library/stdtypes.rst (right):
> 
> http://bugs.python.org/review/23226/diff/13605/Doc/library/stdtypes.rst#newcode1339
> Doc/library/stdtypes.rst:1339: (e.g., by multiplying instead of
> repeating addition), to avoid
> It's not particularly clear what is responsible for accumulated rounding
> errors: multiplication or repeated addition. Perhaps the whole
> explanation in the brackets could be removed?

It's repeated addition, of course. But you're right, easier to just leave that part out than to try to clarify it.

> http://bugs.python.org/review/23226/diff/13605/Doc/library/stdtypes.rst#newcode1346
> Doc/library/stdtypes.rst:1346: values, and potentially being off by 1
> ulp on the :data:`stop` value)
> sorry, what's `ulp'?

Unit of Least Precision. But again, you're right; anyone who already knows what "ulp" means probably doesn't need this paragraph; "digit" is probably clearer.
> 
> http://bugs.python.org/review/23226/diff/13605/Doc/library/stdtypes.rst#newcode1356
> Doc/library/stdtypes.rst:1356: * `linspace recipe
> <http://code.activestate.com/recipes/576694/>`_
> Link leads to OrderedSet recipe

Oops; should be 579000.

> http://bugs.python.org/review/23226/

I'll upload a new patch with these three changes shortly.

From report at bugs.python.org  Wed Jan 14 08:07:25 2015
From: report at bugs.python.org (Lin Wei)
Date: Wed, 14 Jan 2015 07:07:25 +0000
Subject: [docs] [issue20140] UnicodeDecodeError in ntpath.py when home dir
	contains	non-ascii signs
In-Reply-To: <1389005031.99.0.692658963376.issue20140@psf.upfronthosting.co.za>
Message-ID: <1421219245.74.0.160424805115.issue20140@psf.upfronthosting.co.za>


Lin Wei added the comment:

The patch (http://bugs.python.org/issue9291#msg206938) for #9291 actually helps with this issue, at least for me.

By the way, @Serhiy do you mean that the problem is merely documentation, while the implementation is alright?

----------
nosy: +Lin.Wei

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

From report at bugs.python.org  Wed Jan 14 08:26:44 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Jan 2015 07:26:44 +0000
Subject: [docs] [issue23181] Unicode "code point" should be two words in
	documentation
In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za>
Message-ID: <20150114072635.11565.99010@psf.io>


Roundup Robot added the comment:

New changeset c917ba25c007 by Georg Brandl in branch 'default':
Closes #23181: codepoint -> code point
https://hg.python.org/cpython/rev/c917ba25c007

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

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

From report at bugs.python.org  Wed Jan 14 08:41:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Jan 2015 07:41:57 +0000
Subject: [docs] [issue23181] Unicode "code point" should be two words in
	documentation
In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za>
Message-ID: <20150114074117.8759.24204@psf.io>


Roundup Robot added the comment:

New changeset e280a04625cc by Georg Brandl in branch '2.7':
Closes #23181: codepoint -> code point
https://hg.python.org/cpython/rev/e280a04625cc

----------

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

From georg at python.org  Wed Jan 14 08:48:19 2015
From: georg at python.org (Georg Brandl)
Date: Wed, 14 Jan 2015 08:48:19 +0100
Subject: [docs] list.insert(i,x) behavior
In-Reply-To: <CA+YgdAcQWgECz-XZLUmgJqd=2TT8r8KF3yvvoFOCKMvPdwrJqw@mail.gmail.com>
References: <CA+YgdAcQWgECz-XZLUmgJqd=2TT8r8KF3yvvoFOCKMvPdwrJqw@mail.gmail.com>
Message-ID: <54B61F43.8050804@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/12/2015 10:28 AM, pankaj garg wrote:
> Hi Sir/Madam
> 
> I am trying following stuff with lists.
> 
> /*Line 1*/ >>> a = [1,2,3,4,5] */Line 2/* >>> a.insert(5,6) */Line 3/* >>>
> a */Line 5/*        [1,2,3,4,5,6] */Line 6/* >>> a.insert(9,9) */Line 7/*
> >>> a */Line 8/*        [1,2,3,4,5,6,9]
> 
> Output shouldn't be [1,2,3,4,5,6,0,0,0,9] as index specified is */index =
> 9/* */ /* I checked this on */Python 3.4.2/*

Hi Pankaj,

the insert method will only ever insert one item into the list.
Therefore indices greater than len(a) will be capped to it.

This is similar to how slices work: too-large indices are
capped to the highest possible index.

cheers,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlS2H0MACgkQN9GcIYhpnLDFFgCZAXuKxx/p26/I+1QcQsce4q7B
dkAAmgIJwjpYpTv2akafW/D4WtM9vjZE
=h2GF
-----END PGP SIGNATURE-----

From georg at python.org  Wed Jan 14 08:51:09 2015
From: georg at python.org (Georg Brandl)
Date: Wed, 14 Jan 2015 08:51:09 +0100
Subject: [docs] Bug in 3.1.2
In-Reply-To: <CAMLv3x=YC_yU52a6JeW-yWjNPzbOrYkO7B4ErjT+Asv+TNzN1Q@mail.gmail.com>
References: <CAMLv3x=YC_yU52a6JeW-yWjNPzbOrYkO7B4ErjT+Asv+TNzN1Q@mail.gmail.com>
Message-ID: <54B61FED.3000508@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/12/2015 11:56 PM, Navin Senguttuvan wrote:
> Hi , In the section 3.1.2 (strings) , string slice example (the last but
> one example code in the section) , shouldn't the second output be "Pytpy"
> 
> Thanks, Navin

Hi Navin,

I assume you refer to

>>> word = 'Python' 'J' + word[1:]
'Jython'
>>> word[:2] + 'py'
'Pypy'

The upper slice indices, like range() stop values, are exclusive: the
slice [0:2] will use indices 0 and 1.

This can also be expressed by this handy diagram, which appears s few
paragraphs before:

"""
One way to remember how slices work is to think of the indices as pointing
between characters, with the left edge of the first character numbered 0. Then
the right edge of the last character of a string of n characters has index n,
for example:

 +---+---+---+---+---+---+
 | P | y | t | h | o | n |
 +---+---+---+---+---+---+
 0   1   2   3   4   5   6
- -6  -5  -4  -3  -2  -1

"""

cheers,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlS2H+0ACgkQN9GcIYhpnLAluQCfbOGAx/A2+HnPlG7RrEAE8myq
2LIAnirwEEyULG2QLDbGVeoS+fsrkorT
=lrJ6
-----END PGP SIGNATURE-----

From georg at python.org  Wed Jan 14 09:10:23 2015
From: georg at python.org (Georg Brandl)
Date: Wed, 14 Jan 2015 09:10:23 +0100
Subject: [docs] bug
In-Reply-To: <64DF6A98-D6B4-411D-A282-31A0DA076736@gmail.com>
References: <64DF6A98-D6B4-411D-A282-31A0DA076736@gmail.com>
Message-ID: <54B6246F.9020804@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/06/2015 11:11 PM, Nat?lia Padilla Sirera wrote:
> Hi,
> 
> I have done a script that contains
> 
> with open (?file.txt?, ?w?) as fh: fh.write(?blabla1?)
> 
> afterwards I do,
> 
> with open (?FILE.txt?, ?w?) as fh: fh.write(?blabla2?)
> 
> the result is a file called ?file.txt? that contains blabla2
> 
> I think that the name of the file is not case sensitive and I think that it
> should be.

Hi Nat?lia,

this is likely the behavior of your operating system.  On Windows,
file names are always case insensitive.  On MacOS X, this is
configurable for different file systems.

cheers,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlS2JG8ACgkQN9GcIYhpnLDdKgCeJoDbmJpAN8TWr7CVJDYWBZk3
/d8AoK6gE/W4Ac6TcJA/WqpSFnS2rWnC
=CEVs
-----END PGP SIGNATURE-----

From report at bugs.python.org  Wed Jan 14 13:20:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Jan 2015 12:20:22 +0000
Subject: [docs] [issue23181] Unicode "code point" should be two words in
	documentation
In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za>
Message-ID: <1421238022.45.0.129227166267.issue23181@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

"codepoint" is still used in error messages, docstrings and comments.

Doc/library/json.rst:517::class:`str`) codepoints for such sequences.
Lib/email/message.py:276:                    # containing only ASCII codepoints in the unicode input).
Lib/html/entities.py:6:# maps the HTML entity name to the Unicode codepoint
Lib/html/entities.py:2498:# maps the Unicode codepoint to the HTML entity name
Lib/codecs.py:127:         'surrogateescape' - replace with private codepoints U+DCnn.
Lib/test/test_multibytecodec.py:83:        # jisx0213 encoder is stateful for a few codepoints. eg)
Lib/test/test_html.py:51:        # check invalid codepoints
Lib/test/test_html.py:54:        # check more invalid codepoints
Lib/test/multibytecodec_support.py:24:    unmappedunicode = '\udeee' # a unicode codepoint that is not mapped.
Lib/test/test_unicode.py:1473:        # start bytes of a 2-byte sequence equivalent to codepoints < 0x7F
Lib/test/test_unicode.py:1475:        # start bytes of a 4-byte sequence equivalent to codepoints > 0x10FFFF
Lib/test/test_stringprep.py:2:# Since we don't have them, this test checks only a few codepoints.
Tools/unicode/gencodec.py:37:# Placeholder for a missing codepoint
Modules/cjkcodecs/_codecs_hk.c:174:        NEXT_IN(2); /* all decoded codepoints are pairs, above. */
Modules/cjkcodecs/cjkcodecs.h:15:/* a unicode "undefined" codepoint */
Modules/cjkcodecs/cjkcodecs.h:18:/* internal-use DBCS codepoints which aren't used by any charsets */
Modules/cjkcodecs/_codecs_cn.c:18:/* GBK and GB2312 map differently in few codepoints that are listed below:
Modules/cjkcodecs/_codecs_kr.c:72:            /* All codepoints in CP949 extension are in unicode
Modules/unicodedata.c:979:/* macros used to determine if the given codepoint is in the PUA range that
Modules/unicodedata.c:989:    /* Find the name associated with the given codepoint.
Modules/unicodedata.c:1000:    /* XXX should we just skip all the codepoints in the PUAs here? */
Modules/unicodedata.c:1128:    /* if the codepoint is in the PUA range that we use for aliases,
Modules/unicodedata.c:1129:     * convert it to obtain the right codepoint */
Modules/unicodedata.c:1141:    /* Return the codepoint associated with the given name.
Modules/unicodedata.c:1143:     * 3.2.0)).  If with_named_seq is 1, returns the PUA codepoint that we are
Objects/unicodeobject.c:5016:            errmsg = "codepoint in surrogate code point range(0xd800, 0xe000)";
Objects/unicodeobject.c:5035:            errmsg = "codepoint not in range(0x110000)";
Python/sysmodule.c:1382:maxunicode -- the value of the largest Unicode codepoint\n\

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

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

From report at bugs.python.org  Wed Jan 14 13:33:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Jan 2015 12:33:20 +0000
Subject: [docs] [issue23181] Unicode "code point" should be two words in
	documentation
In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za>
Message-ID: <1421238799.51.0.657135869607.issue23181@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which fixes remnants.

----------
Added file: http://bugs.python.org/file37705/code_point_2.patch

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

From report at bugs.python.org  Wed Jan 14 17:11:52 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 14 Jan 2015 16:11:52 +0000
Subject: [docs] [issue23226] Add float linspace recipe to docs
In-Reply-To: <1421102448.57.0.289351503451.issue23226@psf.upfronthosting.co.za>
Message-ID: <1421251912.73.0.648440151543.issue23226@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


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

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

From report at bugs.python.org  Thu Jan 15 05:40:01 2015
From: report at bugs.python.org (N0v1ce Llve)
Date: Thu, 15 Jan 2015 04:40:01 +0000
Subject: [docs] [issue23244] doc typo in 'Glossary': 'generator'
Message-ID: <1421296801.34.0.273749037351.issue23244@psf.upfronthosting.co.za>


New submission from N0v1ce Llve:

'a series a values' in the description of 'generator' in 'Glossary' should be 'a series of values'. 

Take the online documentation for example, the whole sentence is - 
 
> It looks like a normal function except that it contains yield statements for producing **a series a values** usable in a for-loop or that can be retrieved one at a time with the next() function.

:)

----------
assignee: docs at python
components: Documentation
messages: 234047
nosy: docs at python, n0vicelive
priority: normal
severity: normal
status: open
title: doc typo in 'Glossary': 'generator'
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jan 15 05:44:02 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 15 Jan 2015 04:44:02 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict get	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1421297042.26.0.323658198265.issue17546@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Combined the second and last lines, discarded duplication.

----------
nosy: +ethan.furman
versions: +Python 3.5
Added file: http://bugs.python.org/file37711/issue17546.stoneleaf.01.patch

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

From report at bugs.python.org  Thu Jan 15 06:02:36 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 15 Jan 2015 05:02:36 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
	(or	operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1421298156.36.0.289318680475.issue17576@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman

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

From report at bugs.python.org  Thu Jan 15 06:20:52 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 15 Jan 2015 05:20:52 +0000
Subject: [docs] [issue17422] language reference should specify restrictions
	on class	namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1421299252.89.0.220446811203.issue17422@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.5
Added file: http://bugs.python.org/file37712/issue17422.stoneleaf.01.patch

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

From report at bugs.python.org  Thu Jan 15 06:58:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Jan 2015 05:58:30 +0000
Subject: [docs] [issue20467] Confusing wording about __init__
In-Reply-To: <1391208094.95.0.178232051767.issue20467@psf.upfronthosting.co.za>
Message-ID: <20150115055754.8765.1796@psf.io>


Roundup Robot added the comment:

New changeset 94696e457461 by Ethan Furman in branch '3.3':
Issue20467: clarify __init__'s role
https://hg.python.org/cpython/rev/94696e457461

New changeset 46c9b34f31b8 by Ethan Furman in branch '3.4':
Issue20467: clarify __init__'s role
https://hg.python.org/cpython/rev/46c9b34f31b8

New changeset d0421de8ee11 by Ethan Furman in branch 'default':
Issue20467: clarify __init__'s role
https://hg.python.org/cpython/rev/d0421de8ee11

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

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

From report at bugs.python.org  Thu Jan 15 07:02:56 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Jan 2015 06:02:56 +0000
Subject: [docs] [issue20467] Confusing wording about __init__
In-Reply-To: <1391208094.95.0.178232051767.issue20467@psf.upfronthosting.co.za>
Message-ID: <20150115060235.11581.92540@psf.io>


Roundup Robot added the comment:

New changeset 7972b18b6e42 by Ethan Furman in branch '2.7':
Issue20467: clarify __init__'s role
https://hg.python.org/cpython/rev/7972b18b6e42

----------

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

From report at bugs.python.org  Thu Jan 15 07:05:55 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 15 Jan 2015 06:05:55 +0000
Subject: [docs] [issue20467] Confusing wording about __init__
In-Reply-To: <1391208094.95.0.178232051767.issue20467@psf.upfronthosting.co.za>
Message-ID: <1421301955.78.0.627446076241.issue20467@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Changed 'no value may be returned' to 'no non-None value may be returned'.

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

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

From report at bugs.python.org  Thu Jan 15 07:26:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Jan 2015 06:26:35 +0000
Subject: [docs] [issue22988] No error when yielding from `finally`
In-Reply-To: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za>
Message-ID: <20150115062629.3960.61719@psf.io>


Roundup Robot added the comment:

New changeset 0e48b0908651 by Ethan Furman in branch '3.4':
Issue22988: clarify yield and exception blocks
https://hg.python.org/cpython/rev/0e48b0908651

New changeset 55ba19d084fb by Ethan Furman in branch 'default':
Issue22988: clarify yield and exception blocks
https://hg.python.org/cpython/rev/55ba19d084fb

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

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

From report at bugs.python.org  Thu Jan 15 07:27:19 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 15 Jan 2015 06:27:19 +0000
Subject: [docs] [issue22988] No error when yielding from `finally`
In-Reply-To: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za>
Message-ID: <1421303239.72.0.617869672362.issue22988@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


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

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

From report at bugs.python.org  Thu Jan 15 07:32:56 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 15 Jan 2015 06:32:56 +0000
Subject: [docs] [issue22988] No error when yielding from `finally`
In-Reply-To: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za>
Message-ID: <1421303576.88.0.0627101301391.issue22988@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed

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

From report at bugs.python.org  Thu Jan 15 07:32:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Jan 2015 06:32:58 +0000
Subject: [docs] [issue22997] Minor improvements to "Functional API" section
	of Enum	documentation
In-Reply-To: <1417713019.92.0.36560038902.issue22997@psf.upfronthosting.co.za>
Message-ID: <20150115063253.72575.74957@psf.io>


Roundup Robot added the comment:

New changeset 522d13d8e76e by Ethan Furman in branch '3.4':
Issue22997: minor doc update; thanks to Simoen Visser
https://hg.python.org/cpython/rev/522d13d8e76e

New changeset 31ae2dcaaed8 by Ethan Furman in branch 'default':
Issue22997: minor doc update; thanks to Simoen Visser
https://hg.python.org/cpython/rev/31ae2dcaaed8

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

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

From report at bugs.python.org  Thu Jan 15 07:33:35 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 15 Jan 2015 06:33:35 +0000
Subject: [docs] [issue22997] Minor improvements to "Functional API" section
	of Enum	documentation
In-Reply-To: <1417713019.92.0.36560038902.issue22997@psf.upfronthosting.co.za>
Message-ID: <1421303615.03.0.284228076104.issue22997@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thank you, Simeon!

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

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

From report at bugs.python.org  Thu Jan 15 07:36:46 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 15 Jan 2015 06:36:46 +0000
Subject: [docs] [issue22997] Minor improvements to "Functional API" section
	of Enum	documentation
In-Reply-To: <1417713019.92.0.36560038902.issue22997@psf.upfronthosting.co.za>
Message-ID: <1421303806.0.0.685050832067.issue22997@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> fixed

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

From report at bugs.python.org  Thu Jan 15 08:13:50 2015
From: report at bugs.python.org (Mayank Tripathi)
Date: Thu, 15 Jan 2015 07:13:50 +0000
Subject: [docs] [issue23244] doc typo in 'Glossary': 'generator'
In-Reply-To: <1421296801.34.0.273749037351.issue23244@psf.upfronthosting.co.za>
Message-ID: <1421306030.77.0.148760469156.issue23244@psf.upfronthosting.co.za>


Changes by Mayank Tripathi <oquanox at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file37714/generator_typo.patch

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

From report at bugs.python.org  Thu Jan 15 08:16:44 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Jan 2015 07:16:44 +0000
Subject: [docs] [issue23244] doc typo in 'Glossary': 'generator'
In-Reply-To: <1421296801.34.0.273749037351.issue23244@psf.upfronthosting.co.za>
Message-ID: <20150115071633.125910.76691@psf.io>


Roundup Robot added the comment:

New changeset 25a1ce2a6f9b by Georg Brandl in branch '2.7':
Closes #23244: fix typo. Thanks Mayank Tripathi for the patch.
https://hg.python.org/cpython/rev/25a1ce2a6f9b

New changeset 3e4d4c4968bb by Georg Brandl in branch '3.4':
Closes #23244: fix typo. Thanks Mayank Tripathi for the patch.
https://hg.python.org/cpython/rev/3e4d4c4968bb

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

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

From report at bugs.python.org  Thu Jan 15 14:09:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Jan 2015 13:09:41 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict get	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1421327380.94.0.692494038597.issue17546@psf.upfronthosting.co.za>


R. David Murray added the comment:

Your formulation is more concise, thank you.

I suggest dropping the word 'additionally'.  Also, "how it does" would be better phrased as "how it changes", I think.  (It really should be "whether and how it changes", but in deference to Anatoly's 'advanced English' comment I'm willing to let that imprecision slide).

----------

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

From report at bugs.python.org  Thu Jan 15 15:25:02 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 15 Jan 2015 14:25:02 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict get	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1421331902.58.0.0662711313709.issue17546@psf.upfronthosting.co.za>


Martin Panter added the comment:

What about instead of

'''
Whether changes to one are reflected in the other after the call returns is undefined; additionally, the dictionary may change unpredictably after the call, and how it does is implementation-specific.
'''

substitue this wording:

'''
Whether changes to one are reflected in the other after the call returns, and when such updates occur, is undefined and implementation-specific.
'''

The old wording seems under-specified. It would allow a function call, garbage collection, etc, to clobber the dictionary, say overwriting with another function?s locals(), before you get a chance to work with the dictionary.

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

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

From report at bugs.python.org  Thu Jan 15 15:59:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Jan 2015 14:59:23 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict get	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1421333963.23.0.133175030007.issue17546@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, the question of thread-safety in regards to what we are talking about here also occurred to me.  That is, the wording makes one wonder if locals is thread safe or not.  I don't see your suggested wording as making it clearer, though.

The problem is that it *is* underspecified.

So I think the correct description of the current under-specification is that locals() returns a copy of the current locals namespace.  If you modify the thing returned by locals it may or may not update the local namespace.  If you modify the local namespace (by doing x = y or its equivalents) the change may or may not be reflected in the object that was returned by locals().

Now, how do we boil that down?  Or do we just say it more or less that way?

----------

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

From report at bugs.python.org  Fri Jan 16 18:01:06 2015
From: report at bugs.python.org (Akira Li)
Date: Fri, 16 Jan 2015 17:01:06 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
Message-ID: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>


New submission from Akira Li:

There is the corresponding StackOverflow question with 60K view 
"time.sleep ? sleeps thread or process?" [1]

The documentation patch is attached.

[1] http://stackoverflow.com/questions/92928/time-sleep-sleeps-thread-or-process

----------
assignee: docs at python
components: Documentation
files: docs-time.sleep-other-threads-are-not-blocked.diff
keywords: patch
messages: 234135
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: mention in time.sleep() docs that it does not block other Python threads
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37730/docs-time.sleep-other-threads-are-not-blocked.diff

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

From report at bugs.python.org  Fri Jan 16 18:42:06 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Jan 2015 17:42:06 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1421430126.11.0.957025512222.issue23251@psf.upfronthosting.co.za>


R. David Murray added the comment:

Can you re-upload the patch without reflowing the paragraph?  I think the only thing needed is the addition of the word thread, to mirror the equivalent unix man page phrasing, and I think that's what you've done, but I can't easily tell from the provided patch.

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

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

From report at bugs.python.org  Fri Jan 16 22:58:14 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 16 Jan 2015 21:58:14 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1421445494.04.0.896129658147.issue23251@psf.upfronthosting.co.za>


Martin Panter added the comment:

There is also a new sentence about the GIL at the end, but leaving the inbetween lines as they were would verify this

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

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

From report at bugs.python.org  Fri Jan 16 23:56:23 2015
From: report at bugs.python.org (Akira Li)
Date: Fri, 16 Jan 2015 22:56:23 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1421448982.95.0.816238681985.issue23251@psf.upfronthosting.co.za>


Akira Li added the comment:

I do not understand. Have you tried to look at the patch in Rietveld?

The new content is highlighted in a darker green. It is clearly
visible. I've tested on Chromium, Firefox, Safari.

If I won't reflow then the first line will be longer than the
recommended 80 in devguide:

> The maximum line length is 80 characters for normal text, but
> tables, deeply indented code samples and long links may extend
> beyond that.

I've set *fill-column* to 80 in emacs. Do you suggest other settings?

Anyway, it doesn't affect how the final text is shown in a web
browser.

----------

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

From andrew.svetlov at gmail.com  Sat Jan 17 00:15:06 2015
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Sat, 17 Jan 2015 01:15:06 +0200
Subject: [docs] [issue23251] mention in time.sleep() docs that it does
 not block other Python threads
In-Reply-To: <1421448982.95.0.816238681985.issue23251@psf.upfronthosting.co.za>
References: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
 <1421448982.95.0.816238681985.issue23251@psf.upfronthosting.co.za>
Message-ID: <CAL3CFcV7KgKQfLv7rjEV1m464DvdEQLM59d7P3OtSuSxjbNPtA@mail.gmail.com>

I guess R. David Murray asked you to make the least minimal change,
even it breaks the formatting rules.

Paragraph reflow is safe when it's done by the Core Developer but it
requires additional check (and probably mercurial conflict errors on
merging the change with default branch if the last has changes also).

In your case I see no problems though, but the final decision is on R.
David Murray

On Sat, Jan 17, 2015 at 12:56 AM, Akira Li <report at bugs.python.org> wrote:
>
> Akira Li added the comment:
>
> I do not understand. Have you tried to look at the patch in Rietveld?
>
> The new content is highlighted in a darker green. It is clearly
> visible. I've tested on Chromium, Firefox, Safari.
>
> If I won't reflow then the first line will be longer than the
> recommended 80 in devguide:
>
>> The maximum line length is 80 characters for normal text, but
>> tables, deeply indented code samples and long links may extend
>> beyond that.
>
> I've set *fill-column* to 80 in emacs. Do you suggest other settings?
>
> Anyway, it doesn't affect how the final text is shown in a web
> browser.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23251>
> _______________________________________
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs



-- 
Thanks,
Andrew Svetlov

From report at bugs.python.org  Sat Jan 17 00:21:13 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 16 Jan 2015 23:21:13 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1421450473.71.0.340516559978.issue23251@psf.upfronthosting.co.za>


Martin Panter added the comment:

What I have sometimes done in this situation is just break the overly long line into two short lines

----------

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

From report at bugs.python.org  Sat Jan 17 03:51:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Jan 2015 02:51:23 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1421463083.72.0.859674296828.issue23251@psf.upfronthosting.co.za>


R. David Murray added the comment:

I actually didn't know that reitveld was smart enough to highlight just the text changes in a reflowed paragraph.

Nevertheless, for ease of looking at diff in the repository using the hg command (which is not that smart), I prefer to commit doc changes without the reflow, then do the reflow in a separate commit.  I don't know if other developers do this or not.

I think the patch is fine.

----------
stage:  -> commit review
versions: +Python 2.7, Python 3.4

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

From report at bugs.python.org  Sat Jan 17 04:39:19 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 17 Jan 2015 03:39:19 +0000
Subject: [docs] [issue15608] Improve socketserver doc
In-Reply-To: <1344541466.79.0.410789330017.issue15608@psf.upfronthosting.co.za>
Message-ID: <1421465959.67.0.804521052282.issue15608@psf.upfronthosting.co.za>


Martin Panter added the comment:

The post makes a bit more sense once you realize the dotted numbers refer to old section numbers (which have moved on now):

20.19.2 ? ?Server Objects? section
20.19.1 ? ?Server Creation Notes?

Regarding point 2: Instructions for the user to make a threading or forking are still relevant when using a subclass (e.g. HTTPServer) that does not come with a predefined subclass. However documenting which predefined classes exist would be nice too.

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

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

From report at bugs.python.org  Sat Jan 17 04:50:47 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 17 Jan 2015 03:50:47 +0000
Subject: [docs] [issue13354] tcpserver should document non-threaded
	long-living	connections
In-Reply-To: <1320570611.72.0.286817751979.issue13354@psf.upfronthosting.co.za>
Message-ID: <1421466647.3.0.767696830517.issue13354@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jan 17 05:32:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 17 Jan 2015 04:32:55 +0000
Subject: [docs] [issue23254] Document how to close the TCPServer listening
	socket
Message-ID: <1421469175.0.0.628748486385.issue23254@psf.upfronthosting.co.za>


New submission from Martin Panter:

Running the example from the Asynchronous Mixins section of the ?socketserver? documentation generates a ResourceWarning:

$ ./python -btWall ThreadedTCPServer.py
Server loop running in thread: Thread-1
Received: Thread-2: Hello World 1
Received: Thread-3: Hello World 2
Received: Thread-4: Hello World 3
sys:1: ResourceWarning: unclosed <socket.socket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 43804)>

There is a server_close() method mentioned in the doc string of the BaseServer class, so I assume it is meant to be part of the API. But there is no mention of it in the reference documentation.

I think server.server_close() should be documented, and called after server.shutdown() in the example. A further enhancement might be to turn BaseServer into a context manager, but I would be happy with using the existing server_close() method.

----------
assignee: docs at python
components: Documentation
messages: 234161
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Document how to close the TCPServer listening socket
type: enhancement

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

From report at bugs.python.org  Sat Jan 17 05:58:27 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Jan 2015 04:58:27 +0000
Subject: [docs] [issue23220] IDLE does not display \b backspace correctly.
In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za>
Message-ID: <1421470707.77.0.852183213383.issue23220@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Going back to msdos, there are graphic chars for all 256 bytes, including may single and double line box-drawing chars. Many In Idle, I see 5 solid white circles.  In FireFox, there are 5 empty circles (on dark background, which are chr(9689).  When I copy from FF back to Idle (3.4.2, Win7), there are 5 of each. I have no idea if the 9689s are on the site or added by FF.

Here is another difference.

>>> print('\x03')  # console
?  # heart

>>> print('\x03')  # idle
  # lower left single line corner in Idle, box on FF

Trying to match console-Idle(tk) print output for control chars even on Windows would be tough.  
---

I have been planning to add a subsection of the doc that mentions known differences between console interpreter and Idle shell.  The result of print() is one of them.  Another print difference is that Idle displays many unicode chars that Windows replaces with boxes or ?s, depending on the codepage.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, terry.reedy

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

From report at bugs.python.org  Sat Jan 17 17:54:12 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Jan 2015 16:54:12 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1421513652.32.0.59016378924.issue23251@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think it's superfluous to mention the GIL here, since it has no impact on the function.

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

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

From report at bugs.python.org  Sat Jan 17 19:01:25 2015
From: report at bugs.python.org (Akira Li)
Date: Sat, 17 Jan 2015 18:01:25 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1421517685.05.0.894528663465.issue23251@psf.upfronthosting.co.za>


Akira Li added the comment:

> I think it's superfluous to mention the GIL here, since it has no impact on the function.

If GIL is not released then all Python code in other threads is 
effectively blocked.
It is worth mentioning explicitly that it is guaranteed to be released
during the sleep.

----------

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

From report at bugs.python.org  Sat Jan 17 19:03:47 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Jan 2015 18:03:47 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1421517827.11.0.420423604116.issue23251@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> If GIL is not released then all Python code in other threads is 
> effectively blocked.

But that would be a stupid implementation of sleep(). It is not desirable to clutter the docs with such mentions: most calls to the OS in the stdlib release the GIL.

Only if the behaviour was unintuitive (i.e. if it *didn't* release the GIL) would it make sense to document it.

----------

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

From report at bugs.python.org  Sat Jan 17 19:35:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Jan 2015 18:35:58 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1421519758.12.0.957858645713.issue23251@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, on consideration I agree with Antoine.  That last sentence should be deleted.  Otherwise we'd need to mention that the gil was released every place that the gil was released, which would be very redundant.  The general rule is that anything that blocks in python releases the GIL, therefore as Antoine says the only time we need to document GIL behavior is when that *doesn't* happen.

----------

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

From report at bugs.python.org  Sun Jan 18 07:32:34 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 18 Jan 2015 06:32:34 +0000
Subject: [docs] [issue20121] quopri_codec newline handling
In-Reply-To: <1388836490.83.0.337537980753.issue20121@psf.upfronthosting.co.za>
Message-ID: <1421562753.9.0.1137991851.issue20121@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch that clarifies in the documentation and test suite how newlines work in the ?quopri? and ?binascii? modules. It also fixes the native Python implementation to support CRLFs.

* \n is used by default (e.g. for soft line breaks if the input has no hard line breaks)
* CRLF is used instead if found in input (even in non-text mode!)
* Typo errors in documentation
* quopri uses istext=True
* header flag does not affect newline encoding; only istext affects it

One corner case concerns me slightly: binascii.b2a_qp(istext=False) will use \n for soft line breaks by default, but will suddenly switch to CRLF if the input data happens to contain a CRLF sequence. This is despite the CRLFs from the data being encoded and therefore not appearing in the output themselves.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +patch
nosy: +docs at python
Added file: http://bugs.python.org/file37756/quopri-newline.patch

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

From report at bugs.python.org  Sun Jan 18 09:22:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Jan 2015 08:22:14 +0000
Subject: [docs] [issue23181] Unicode "code point" should be two words in
	documentation
In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za>
Message-ID: <1421569334.96.0.00411040055581.issue23181@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jan 18 09:33:47 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2015 08:33:47 +0000
Subject: [docs] [issue23181] Unicode "code point" should be two words in
	documentation
In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za>
Message-ID: <1421570027.38.0.897743802515.issue23181@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Well, go ahead I guess.

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

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

From report at bugs.python.org  Sun Jan 18 10:45:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Jan 2015 09:45:18 +0000
Subject: [docs] [issue23181] Unicode "code point" should be two words in
	documentation
In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za>
Message-ID: <20150118094514.69906.84841@psf.io>


Roundup Robot added the comment:

New changeset 0353c7e5e0c2 by Serhiy Storchaka in branch '3.4':
Issue #23181: More "codepoint" -> "code point".
https://hg.python.org/cpython/rev/0353c7e5e0c2

New changeset c79abee84a39 by Serhiy Storchaka in branch 'default':
Issue #23181: More "codepoint" -> "code point".
https://hg.python.org/cpython/rev/c79abee84a39

New changeset 2db41d551a4f by Serhiy Storchaka in branch '2.7':
Issue #23181: More "codepoint" -> "code point".
https://hg.python.org/cpython/rev/2db41d551a4f

----------

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

From report at bugs.python.org  Sun Jan 18 10:48:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Jan 2015 09:48:54 +0000
Subject: [docs] [issue23181] Unicode "code point" should be two words in
	documentation
In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za>
Message-ID: <1421574534.41.0.997864959661.issue23181@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> serhiy.storchaka
status: open -> closed

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

From report at bugs.python.org  Sun Jan 18 11:01:45 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Jan 2015 10:01:45 +0000
Subject: [docs] [issue18518] return-ing within code timed with timeit.timeit
	causes	wrong return value of timeit.timeit
In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za>
Message-ID: <1421575305.54.0.532360972909.issue18518@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If there are no objections I'm going to commit the patch.

----------
assignee:  -> serhiy.storchaka

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

From report at bugs.python.org  Sun Jan 18 15:36:41 2015
From: report at bugs.python.org (Akira Li)
Date: Sun, 18 Jan 2015 14:36:41 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1421591801.5.0.953693832025.issue23251@psf.upfronthosting.co.za>


Akira Li added the comment:

> Only if the behaviour was unintuitive (i.e. if it *didn't* release the
> GIL) would it make sense to document it.

There is no intuitive interface, not even the nipple. It's all learned. [1]

> Yes, on consideration I agree with Antoine.  That last sentence should
> be deleted.  Otherwise we'd need to mention that the gil was released
> every place that the gil was released, which would be very redundant.

Whether or not other places mention it is unrelated to the current
issue.

Though the documentation should mention it more. Many programmers are
convinced that Python threads can't be executed in parallel.

> The general rule is that anything that blocks in python releases the
> GIL, therefore as Antoine says the only time we need to document GIL
> behavior is when that *doesn't* happen.

The reader of Python documentation is intelegent but not all-knowing.

"Blocking" is the first and only job for time.sleep() function.
GIL "blocks" Python code.
You can't understand what time.sleep does without knowing what happens
to GIL.

Ask yourself who and why reads the time.sleep() documentation (novice
and/or exprerienced Python user). Put yourself into the mind of the
reader.


[1] http://www.greenend.org.uk/rjk/misc/nipple.html

----------

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

From report at bugs.python.org  Sun Jan 18 15:39:56 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jan 2015 14:39:56 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1421591996.48.0.614296960441.issue23251@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Please let's stop it. Mentioning the GIL in every place in the documentation will only make people more worried and confused about something they shouldn't be confused or worried about.

If you think some docs should discuss the GIL and its effect on running threads then I suggest writing a separate document (a HOWTO for example, like the Unicode HOWTO).

----------

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

From report at bugs.python.org  Sun Jan 18 22:35:21 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 18 Jan 2015 21:35:21 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421591996.48.0.614296960441.issue23251@psf.upfronthosting.co.za>
Message-ID: <CAL3CFcX4KjpmbN9TehYKGzd5hHUH-+E1j1ivtYG5W8OtdpS+eg@mail.gmail.com>


Andrew Svetlov added the comment:

I'm with Antoine.

Yes, GIL is extremely important but please don't put GIL mentions everywhere.

On Sun, Jan 18, 2015 at 4:39 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou added the comment:
>
> Please let's stop it. Mentioning the GIL in every place in the documentation will only make people more worried and confused about something they shouldn't be confused or worried about.
>
> If you think some docs should discuss the GIL and its effect on running threads then I suggest writing a separate document (a HOWTO for example, like the Unicode HOWTO).
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23251>
> _______________________________________

----------

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

From report at bugs.python.org  Sun Jan 18 22:47:37 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2015 21:47:37 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1421617657.78.0.794456087521.issue23251@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Agreed. "of the current thread" is a good addition.  The sleep() docs are already longer than I would like.

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

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

From report at bugs.python.org  Mon Jan 19 02:31:35 2015
From: report at bugs.python.org (Anne Moroney)
Date: Mon, 19 Jan 2015 01:31:35 +0000
Subject: [docs] [issue22317] action argument is not documented in
	argparse	add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <1421631094.94.0.988901186668.issue22317@psf.upfronthosting.co.za>


Anne Moroney added the comment:

This ticket's patch appears to have already been merged, yet it is open? 

On 2.7.9 docs [1], it has the exact language. The tutorial page [2] has a nice description as well. Finding this ticket really helped me understand argparse a bit better, and now I vote to close :).
AnneTheAgile, inspired by CodeTriage

1.[] ; ; ; ; ; ; ; ; ; ;  X.15.4. argparse ? Parser for command-line options, arguments and sub-commands ? Python 2.7.9 documentation
https://docs.python.org/2/library
action - The basic type of action to be taken when this argument is encountered at the command line.

2.[] ; ; ; ; ; ; ; ; ; ;  X.Argparse Tutorial ? Python 2.7.9 documentation
https://docs.python.org/2/howto/argparse.html
we now specify a new keyword, action, and give it the value "store_true". This means that, if the option is specified, assign the value True to args.verbose. Not specifying it implies False.

3.[] ; ;List of all types of 'action', including customizable ; ; ; ; ; ; ; ;  X.15.4. argparse ? Parser for command-line options, arguments and sub-commands ? Python 2.7.9 documentation
https://docs.python.org/2/library/argparse.html#action
action="store_true"
action='store_false'
action="count"
action='store_const'
action='append'
action='version'
action=CustomFooAction

----------
nosy: +AnneTheAgile

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

From report at bugs.python.org  Mon Jan 19 06:46:36 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Jan 2015 05:46:36 +0000
Subject: [docs] [issue16473] quopri module differences in quoted-printable
	text with	whitespace
In-Reply-To: <1352928126.09.0.115783436578.issue16473@psf.upfronthosting.co.za>
Message-ID: <1421646396.55.0.543979122118.issue16473@psf.upfronthosting.co.za>


Martin Panter added the comment:

Three slightly different points here:

1. Decoding trailing whitespace: My understanding is quoted-printable encoding aims to be tolerant of whitespace being added to and removed from the end of encoded lines. So I assume the ?binascii? module is wrong to leave trailing whitespace in the decoded output, and the native ?quopri? implementation is correct to ignore it.

2. CRLF handling: See Issue 20121. It seems CRLF newlines should be valid, and I have added a patch to that issue to make the native Python implementation handle CRLF newlines.

3. Whitespace encoding: The quopri-codec actually sets quotetabs=True. Here is a patch to document and test that, as well as correct the functions used by other codecs.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, vadmium
title: quopri module minor difference in decoding quoted-printable text -> quopri module differences in quoted-printable text with whitespace
Added file: http://bugs.python.org/file37772/codec-impl.patch

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

From report at bugs.python.org  Mon Jan 19 07:26:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Jan 2015 06:26:53 +0000
Subject: [docs] [issue16473] quopri module differences in quoted-printable
	text with	whitespace
In-Reply-To: <1352928126.09.0.115783436578.issue16473@psf.upfronthosting.co.za>
Message-ID: <1421648813.75.0.748791870378.issue16473@psf.upfronthosting.co.za>


Martin Panter added the comment:

Regarding decoding trailing whitespace, <https://tools.ietf.org/html/rfc1521.html#section-5.1> rule #3 says:

?When decoding a Quoted-Printable body, any trailing white space on a line must be deleted, as it will necessarily have been added by intermediate transport agents.?

----------

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

From report at bugs.python.org  Mon Jan 19 14:56:59 2015
From: report at bugs.python.org (Dionysis Zindros)
Date: Mon, 19 Jan 2015 13:56:59 +0000
Subject: [docs] [issue23271] Unicode HOWTO documentation error
Message-ID: <1421675819.3.0.538078693406.issue23271@psf.upfronthosting.co.za>


New submission from Dionysis Zindros:

In the Unicode HOTWO documentation for Python 2.x [0], there's an error in the fourth code sample under the section "The Unicode Type".

The code states:

```
>>> s = u'Was ever feather so lightly blown to and fro as this multitude?'
>>> s.count('e')
5
>>> s.find('feather')
9
>>> s.find('bird')
-1
>>> s.replace('feather', 'sand')
u'Was ever sand so lightly blown to and fro as this multitude?'
>>> s.upper()
u'WAS EVER FEATHER SO LIGHTLY BLOWN TO AND FRO AS THIS MULTITUDE?'
```

Notice that in the last line, "sand" was turned back into "feather". The correct last line should have been:

```
u'WAS EVER SAND SO LIGHTLY BLOWN TO AND FRO AS THIS MULTITUDE?'
```

[0] https://docs.python.org/2/howto/unicode.html

----------
assignee: docs at python
components: Documentation
messages: 234312
nosy: Dionysis.Zindros, docs at python
priority: normal
severity: normal
status: open
title: Unicode HOWTO documentation error
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan 19 15:13:54 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 19 Jan 2015 14:13:54 +0000
Subject: [docs] [issue23271] Unicode HOWTO documentation error
In-Reply-To: <1421675819.3.0.538078693406.issue23271@psf.upfronthosting.co.za>
Message-ID: <1421676834.33.0.886161957596.issue23271@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

The example is correct. If you type it into a python interpreter, you get the results as shown in the example.

The .replace() method does not modify the string s. It returns the new value. In the example, the new value is displayed, but is not assigned back to s, so s does not change.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: enhancement -> 

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

From report at bugs.python.org  Tue Jan 20 05:44:00 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 20 Jan 2015 04:44:00 +0000
Subject: [docs] [issue20121] quopri_codec newline handling
In-Reply-To: <1388836490.83.0.337537980753.issue20121@psf.upfronthosting.co.za>
Message-ID: <1421729040.48.0.546858290146.issue20121@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is patch v2, which fixes some more bugs I uncovered in the quoted-printable encoders:

* The binascii version would unnecessarily break a 76-character line (maximum length) if it would end with an =XX escape code
* The native Python version would insert soft line breaks in the middle of =XX escape codes

----------
type:  -> behavior
Added file: http://bugs.python.org/file37783/quopri-newline.v2.patch

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

From report at bugs.python.org  Tue Jan 20 05:46:45 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Jan 2015 04:46:45 +0000
Subject: [docs] [issue22317] action argument is not documented in
	argparse	add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <20150120044642.69916.5392@psf.io>


Roundup Robot added the comment:

New changeset 350b8e109c42 by Berker Peksag in branch '3.4':
Issue #22317: Document the action parameter in ArgumentParser.add_subparsers() docs.
https://hg.python.org/cpython/rev/350b8e109c42

New changeset 4709290253e3 by Berker Peksag in branch 'default':
Issue #22317: Document the action parameter in ArgumentParser.add_subparsers() docs.
https://hg.python.org/cpython/rev/4709290253e3

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

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

From report at bugs.python.org  Tue Jan 20 05:55:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Jan 2015 04:55:47 +0000
Subject: [docs] [issue22317] action argument is not documented in
	argparse	add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <20150120045542.69900.134@psf.io>


Roundup Robot added the comment:

New changeset 430236ef507b by Berker Peksag in branch '2.7':
Issue #22317: Document the action parameter in ArgumentParser.add_subparsers() docs.
https://hg.python.org/cpython/rev/430236ef507b

----------

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

From report at bugs.python.org  Tue Jan 20 05:56:55 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 20 Jan 2015 04:56:55 +0000
Subject: [docs] [issue22317] action argument is not documented in
	argparse	add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <1421729815.37.0.482337728243.issue22317@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Mike.

Anne, thank you for the ticket triage! The only missing place was the ArgumentParser.add_subparsers() documentation: https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_subparsers

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

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

From report at bugs.python.org  Tue Jan 20 06:04:41 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 20 Jan 2015 05:04:41 +0000
Subject: [docs] [issue20702] warning in cmdline.rst
In-Reply-To: <1392912711.56.0.068160127769.issue20702@psf.upfronthosting.co.za>
Message-ID: <1421730280.97.0.959676701509.issue20702@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I couldn't reproduce it with Sphinx 1.2.3. The only warning I got was

    Doc/whatsnew/3.4.rst:2138: WARNING: undefined label: idle (if the link has no caption the label must precede a section header)

----------
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Jan 21 00:09:22 2015
From: report at bugs.python.org (aruseni)
Date: Tue, 20 Jan 2015 23:09:22 +0000
Subject: [docs] [issue23286] A typo in the tutorial
Message-ID: <1421795362.32.0.373442891805.issue23286@psf.upfronthosting.co.za>


New submission from aruseni:

https://docs.python.org/3/tutorial/introduction.html

> Lists also supports operations like concatenation

----------
assignee: docs at python
components: Documentation
messages: 234401
nosy: aruseni, docs at python
priority: normal
severity: normal
status: open
title: A typo in the tutorial

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

From report at bugs.python.org  Wed Jan 21 11:02:03 2015
From: report at bugs.python.org (Mayank Tripathi)
Date: Wed, 21 Jan 2015 10:02:03 +0000
Subject: [docs] [issue23286] A typo in the tutorial
In-Reply-To: <1421795362.32.0.373442891805.issue23286@psf.upfronthosting.co.za>
Message-ID: <1421834523.25.0.605518861856.issue23286@psf.upfronthosting.co.za>


Changes by Mayank Tripathi <oquanox at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file37804/intro_typo.diff

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

From report at bugs.python.org  Wed Jan 21 11:37:56 2015
From: report at bugs.python.org (Mike Sampson)
Date: Wed, 21 Jan 2015 10:37:56 +0000
Subject: [docs] [issue23288] subprocess.Popen close_fds behaviour differs
	between 3.2	and 3.4
Message-ID: <1421836676.03.0.70112175637.issue23288@psf.upfronthosting.co.za>


New submission from Mike Sampson:

I'm seeing differing behaviour with subprocess.Popen(..., close_fds = False) between 3.2 and 3.4. The docs don't say this is meant to be the case as far as I can see.

Python 3.2.3 on Debian Wheezy
=============================

>>> import subprocess
>>> import os
>>> r,w = os.pipe()
>>> p = subprocess.Popen('ls /dev/fd/*', shell = True, close_fds = False)
>>> ls: cannot access /dev/fd/5: No such file or directory
/dev/fd/0  /dev/fd/1  /dev/fd/2  /dev/fd/3  /dev/fd/4

Python 3.4.2 on Arch Linux
==========================

>>> import subprocess
>>> import os
>>> r,w = os.pipe()
>>> p = subprocess.Popen('ls /dev/fd/*', shell = True, close_fds = False)                                                                                                            
>>> ls: cannot access /dev/fd/3: No such file or directory
/dev/fd/0  /dev/fd/1  /dev/fd/2

In 3.4 even though close_fds is False the fds are closed in the child. Using pass_fds works around this though I would like to know if this is a bug, documentation issue, or am I missing something here?

----------
assignee: docs at python
components: Documentation
messages: 234428
nosy: docs at python, mfs
priority: normal
severity: normal
status: open
title: subprocess.Popen close_fds behaviour differs between 3.2 and 3.4
type: behavior
versions: Python 3.2, Python 3.4

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

From report at bugs.python.org  Wed Jan 21 11:39:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Jan 2015 10:39:19 +0000
Subject: [docs] [issue23288] subprocess.Popen close_fds behaviour differs
	between 3.2	and 3.4
In-Reply-To: <1421836676.03.0.70112175637.issue23288@psf.upfronthosting.co.za>
Message-ID: <1421836759.56.0.797903681278.issue23288@psf.upfronthosting.co.za>


STINNER Victor added the comment:

File descriptors are not closed, but not inherited neither, in Python 3.4. See the PEP 446.

To have a reliable behaviour on all platforms and all Python versions, just use the pass_fds parameter.

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

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

From report at bugs.python.org  Wed Jan 21 11:40:22 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Jan 2015 10:40:22 +0000
Subject: [docs] [issue23288] subprocess.Popen close_fds behaviour differs
	between 3.2	and 3.4
In-Reply-To: <1421836676.03.0.70112175637.issue23288@psf.upfronthosting.co.za>
Message-ID: <1421836822.57.0.181522372698.issue23288@psf.upfronthosting.co.za>


STINNER Victor added the comment:

https://docs.python.org/dev/library/os.html#os.pipe

Changed in version 3.4: The new file descriptors are now non-inheritable.

If you don't use the subprocess module, you may use os.set_inheritable().
https://docs.python.org/dev/library/os.html#os.set_inheritable

----------

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

From report at bugs.python.org  Wed Jan 21 11:43:08 2015
From: report at bugs.python.org (Mike Sampson)
Date: Wed, 21 Jan 2015 10:43:08 +0000
Subject: [docs] [issue23288] subprocess.Popen close_fds behaviour differs
	between 3.2	and 3.4
In-Reply-To: <1421836676.03.0.70112175637.issue23288@psf.upfronthosting.co.za>
Message-ID: <1421836988.13.0.461337608101.issue23288@psf.upfronthosting.co.za>


Mike Sampson added the comment:

Ah, got it. Didn't see the note on the os.pipe() docs. Thanks. Closing. Sorry for the noise.

----------

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

From report at bugs.python.org  Wed Jan 21 11:43:25 2015
From: report at bugs.python.org (Mike Sampson)
Date: Wed, 21 Jan 2015 10:43:25 +0000
Subject: [docs] [issue23288] subprocess.Popen close_fds behaviour differs
	between 3.2	and 3.4
In-Reply-To: <1421836676.03.0.70112175637.issue23288@psf.upfronthosting.co.za>
Message-ID: <1421837005.79.0.204870861996.issue23288@psf.upfronthosting.co.za>


Changes by Mike Sampson <mike at sambodata.com>:


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

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

From report at bugs.python.org  Wed Jan 21 15:37:30 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Jan 2015 14:37:30 +0000
Subject: [docs] [issue23288] subprocess.Popen close_fds behaviour differs
	between 3.2	and 3.4
In-Reply-To: <1421836676.03.0.70112175637.issue23288@psf.upfronthosting.co.za>
Message-ID: <1421851050.18.0.701585542146.issue23288@psf.upfronthosting.co.za>


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


----------
resolution:  -> not a bug
stage:  -> resolved

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

From report at bugs.python.org  Wed Jan 21 21:00:29 2015
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 21 Jan 2015 20:00:29 +0000
Subject: [docs] [issue23292] Enum doc suggestion
Message-ID: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

I think it would be worth documenting
globals().update(MyEnumeration.__members__) in the "Interesting
Examples" section of the enum docs.

I suspect that most people will find that importing enums is annoying
because they'll get

import A
print(A.MyEnumeration.MAX)

when they're more used to

import A
print(A.MAX)

Of course the latter is easily achieved using the globals().update()
trick (as used in signals.py in 3.5).

Georg suggested I add this to the tracker.

----------
assignee: docs at python
components: Documentation
files: py-enum.tar.gz
messages: 234442
nosy: docs at python, mark
priority: normal
severity: normal
status: open
title: Enum doc suggestion
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37809/py-enum.tar.gz

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

From report at bugs.python.org  Wed Jan 21 21:01:30 2015
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 21 Jan 2015 20:01:30 +0000
Subject: [docs] [issue23292] Enum doc suggestion
In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>
Message-ID: <1421870490.66.0.299225627722.issue23292@psf.upfronthosting.co.za>


Mark Summerfield added the comment:

Georg said to assign this to Ethan Furman but I don't seem to have that facility.

----------

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

From report at bugs.python.org  Wed Jan 21 21:13:32 2015
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 21 Jan 2015 20:13:32 +0000
Subject: [docs] [issue23292] Enum doc suggestion
In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>
Message-ID: <1421871212.17.0.916155108456.issue23292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: docs at python -> ethan.furman
nosy: +ethan.furman

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

From report at bugs.python.org  Wed Jan 21 23:34:29 2015
From: report at bugs.python.org (aruseni)
Date: Wed, 21 Jan 2015 22:34:29 +0000
Subject: [docs] [issue23294] A typo in the tutorial
In-Reply-To: <1421879644.03.0.144985173362.issue23294@psf.upfronthosting.co.za>
Message-ID: <1421879669.65.0.0486271210032.issue23294@psf.upfronthosting.co.za>


Changes by aruseni <aruseni.magiku at gmail.com>:


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

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

From report at bugs.python.org  Thu Jan 22 02:46:07 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 22 Jan 2015 01:46:07 +0000
Subject: [docs] [issue23294] A typo in the tutorial
In-Reply-To: <1421879644.03.0.144985173362.issue23294@psf.upfronthosting.co.za>
Message-ID: <1421891167.07.0.119264523935.issue23294@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

What's the typo? I'm not seeing it.

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

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

From roger at kistruck.co.uk  Tue Jan 20 22:18:11 2015
From: roger at kistruck.co.uk (Roger)
Date: Tue, 20 Jan 2015 21:18:11 +0000
Subject: [docs] python-smbus and repeated starts
Message-ID: <BBEF091A-E48A-4081-A232-493B3A9AAF0C@kistruck.co.uk>

Greetings, 

	I am a moderately ignorant near-beginner with Python. I have a problem with trying to read a particular sensor chip attached to the i2c bus connections of a Raspberry Pi. The sensor is the MMA8451Q by Freescale Semiconductor; a well-established device with good performance and more features than I am likely to need in a long while. 

I have managed to read a different sensor (ADXL345) on the same i2c bus, using the standard tools available in Linux (I am using Raspbian on the Pi), so I have successfully used a handful of commands from the smbus repertory. I had to learn how to do it by copying from a previous piece of code written by someone else. 

Unfortunately for me, the MMA8451 _requires_ repeated start commands to read its data registers, and I cannot find any documentation that covers it. I have looked at the Python official documentation, and a search for 'smbus' or 'i2c' yields no search results at all. I have spent a good many hours thrashing through Google too, and also Github, and failed to find any useful leads. See : 

<http://wiki.erazor-zone.de/wiki:linux:python:smbus:doc>  and 
<http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/i2c/smbus-protocol>  and 
<http://www.raspberrypi.org/forums/viewtopic.php?p=603520#603520>

What seems to be missing is anything about the Python SMBus module to explain how it handles the crucial elements of the i2c protocol, and when it uses repeated-start signals in particular. 

It may be that I have not been very clever in finding what is there, but if so I would be glad to know. 

With thanks for any help you can give. 

Roger
--
Roger Kistruck
5 The Limes
Long Melford
Sudbury
Suffolk
CO10 9SX
UK
phone: +44 1787 311165
mobile: +44 7791 185660






From massimiliano.deruosi at gmail.com  Wed Jan 21 10:01:30 2015
From: massimiliano.deruosi at gmail.com (Massimiliano De Ruosi)
Date: Wed, 21 Jan 2015 10:01:30 +0100
Subject: [docs] bug in italian translation of python tutorial (and bug
 tracker link not working)
Message-ID: <CADXwms75UKKTGYzmCOX7fu3sVfaEzdmu4jnmXRKLj85o-rHyNg@mail.gmail.com>

Hi,

I tried to report a bug in italian translation of "Python tutorial",
but the link of "Python Bug Tracker" at:
http://docs.python.it/html/tut/about.html didn't work (404 error)

The bug was in http://docs.python.it/html/tut/node11.html#SECTION0011800000000000000000

(9.8) "raise C()" should be: "raise c()"

Regards,
Max

-- 
Massimiliano De Ruosi
Cell. +39 320 4350861

From vishu1809 at hotmail.com  Wed Jan 21 12:26:30 2015
From: vishu1809 at hotmail.com (its_ vishu)
Date: Wed, 21 Jan 2015 11:26:30 +0000
Subject: [docs] Error
Message-ID: <BLU179-W821F67B46781D5F861ECB1BE480@phx.gbl>

Hi Team,
I'm using python 3.4.2. I'm a newbie, interested in learning python. 
I found the following error while practising fibonacci example on the python 3.4 command line.
Kindly help me in solving the error. Thanks.

Regards,Vishu. 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150121/341dd99a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py.png
Type: image/png
Size: 9879 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20150121/341dd99a/attachment.png>

From zachary.ware+pydocs at gmail.com  Thu Jan 22 06:35:23 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 21 Jan 2015 23:35:23 -0600
Subject: [docs] bug in italian translation of python tutorial (and bug
 tracker link not working)
In-Reply-To: <CADXwms75UKKTGYzmCOX7fu3sVfaEzdmu4jnmXRKLj85o-rHyNg@mail.gmail.com>
References: <CADXwms75UKKTGYzmCOX7fu3sVfaEzdmu4jnmXRKLj85o-rHyNg@mail.gmail.com>
Message-ID: <CAKJDb-MhbNoTaMQUb-9XP_SiFUj+6A++ya91duxmFj8fCShOAA@mail.gmail.com>

Hi,

On Wed, Jan 21, 2015 at 3:01 AM, Massimiliano De Ruosi
<massimiliano.deruosi at gmail.com> wrote:
> Hi,
>
> I tried to report a bug in italian translation of "Python tutorial",
> but the link of "Python Bug Tracker" at:
> http://docs.python.it/html/tut/about.html didn't work (404 error)
>
> The bug was in http://docs.python.it/html/tut/node11.html#SECTION0011800000000000000000
>
> (9.8) "raise C()" should be: "raise c()"

Thanks for the report, but unfortunately there's nothing we can do
about it.  Firstly, docs.python.it is not related to docs.python.org,
which is the site this list is concerned with.  There are (as far as I
know) no official translations of the Python documentation
(unfortunately).  Secondly, the documentation on that site is for
Python 2.3.4, which is over 10 years old and has been out of
maintenance for several years now.  Python has moved on quite some
distance since then (the current version is 3.4.2, or 2.7.9 if you're
stuck with Python2)!  Also, the bug tracker link on the page you
linked to is no longer valid because Python's development moved from
SourceForge to self-hosted infrastructure sometime around mid-2007.
The new bug tracker is at bugs.python.org.  A more recent (though
strictly English) tutorial can be found at docs.python.org/3/tutorial.

Sorry I can't be of any more help,
-- 
Zach

From zachary.ware+pydocs at gmail.com  Thu Jan 22 06:38:02 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 21 Jan 2015 23:38:02 -0600
Subject: [docs] python-smbus and repeated starts
In-Reply-To: <BBEF091A-E48A-4081-A232-493B3A9AAF0C@kistruck.co.uk>
References: <BBEF091A-E48A-4081-A232-493B3A9AAF0C@kistruck.co.uk>
Message-ID: <CAKJDb-PdZkSc2TYmGp48-LDiBNL=+pkw9MYu_bCxz3n0uFGFmQ@mail.gmail.com>

Hi Roger,

This is not the appropriate venue for usage questions such as this;
this list is meant for discussion of the Python documentation.  You'll
have better luck asking on the main Python mailing list,
python-list at python.org.

Regards,
--
Zach

On Tue, Jan 20, 2015 at 3:18 PM, Roger <roger at kistruck.co.uk> wrote:
> Greetings,
>
>         I am a moderately ignorant near-beginner with Python. I have a problem with trying to read a particular sensor chip attached to the i2c bus connections of a Raspberry Pi. The sensor is the MMA8451Q by Freescale Semiconductor; a well-established device with good performance and more features than I am likely to need in a long while.
>
> I have managed to read a different sensor (ADXL345) on the same i2c bus, using the standard tools available in Linux (I am using Raspbian on the Pi), so I have successfully used a handful of commands from the smbus repertory. I had to learn how to do it by copying from a previous piece of code written by someone else.
>
> Unfortunately for me, the MMA8451 _requires_ repeated start commands to read its data registers, and I cannot find any documentation that covers it. I have looked at the Python official documentation, and a search for 'smbus' or 'i2c' yields no search results at all. I have spent a good many hours thrashing through Google too, and also Github, and failed to find any useful leads. See :
>
> <http://wiki.erazor-zone.de/wiki:linux:python:smbus:doc>  and
> <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/i2c/smbus-protocol>  and
> <http://www.raspberrypi.org/forums/viewtopic.php?p=603520#603520>
>
> What seems to be missing is anything about the Python SMBus module to explain how it handles the crucial elements of the i2c protocol, and when it uses repeated-start signals in particular.
>
> It may be that I have not been very clever in finding what is there, but if so I would be glad to know.
>
> With thanks for any help you can give.
>
> Roger
> --
> Roger Kistruck
> 5 The Limes
> Long Melford
> Sudbury
> Suffolk
> CO10 9SX
> UK
> phone: +44 1787 311165
> mobile: +44 7791 185660

From zachary.ware+pydocs at gmail.com  Thu Jan 22 06:46:42 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 21 Jan 2015 23:46:42 -0600
Subject: [docs] Error
In-Reply-To: <BLU179-W821F67B46781D5F861ECB1BE480@phx.gbl>
References: <BLU179-W821F67B46781D5F861ECB1BE480@phx.gbl>
Message-ID: <CAKJDb-NbeDe63tN0o7=cPAa7J+jNhm02Dc1TS3Uj-UYQhRpuEw@mail.gmail.com>

Hi Vishu,

On Wed, Jan 21, 2015 at 5:26 AM, its_ vishu <vishu1809 at hotmail.com> wrote:
> Hi Team,
>
> I'm using python 3.4.2. I'm a newbie, interested in learning python.
>
> I found the following error while practising fibonacci example on the python
> 3.4 command line.
>
> Kindly help me in solving the error. Thanks.

This is not the appropriate place to ask for help in using Python;
this list is meant for discussion of the Python documentation.  You
would be better served to try the main Python mailing list
(python-list at python.org) or the Python Tutor mailing list
(tutor at python.org) for any further questions.  It would also be much
better to copy and paste the output rather than attaching a screenshot
(if you're using Command Prompt, right click and choose "Mark", then
click and drag to highlight a rectangular area and hit the "enter" key
to copy it).

That said, indentation is significant in Python; the end of a logical
block is delineated by a change in indention level.  As the error
message in your screenshot says, the parser expected the line after
"while ...:" to be indented, but you did not indent.  Just add one or
more spaces or tabs (but not both :)) before your "print" call.

Regards,
-- 
Zach

From report at bugs.python.org  Thu Jan 22 09:53:41 2015
From: report at bugs.python.org (Liang Zhang)
Date: Thu, 22 Jan 2015 08:53:41 +0000
Subject: [docs] [issue23299] Documentation correction - 5.1.4. List
	Comprehensions
Message-ID: <1421916821.61.0.582688428376.issue23299@psf.upfronthosting.co.za>


New submission from Liang Zhang:

This was copied from Chapter 5 Data Structure in Python language tutorial.

The link I was looking for:  https://docs.python.org/2.7/tutorial/datastructures.html

Some thing might be incorrect and need you to update them in
(5.1.4. List Comprehensions)

It should be like this:
------------------start------------------
>>> vec = [-4, -2, 0, 2, 4]
>>> # create a new list with the values doubled
>>> [x*2 for x in vec]
[-8, -4, 0, 4, 8]
>>> # filter the list to exclude negative numbers
>>> [x for x in vec if x >= 0]
[0, 2, 4]
>>> # apply a function to all the elements
>>> [abs(x) for x in vec]
[4, 2, 0, 2, 4]                     >>>>>>>>>>>It should be [0, 2, 4]<<<<<<<<<<<
------------------end------------------

----------
assignee: docs at python
components: Documentation
messages: 234485
nosy: Liang.Zhang, docs at python
priority: normal
severity: normal
status: open
title: Documentation correction - 5.1.4. List Comprehensions
type: resource usage
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/issue23299>
_______________________________________

From report at bugs.python.org  Thu Jan 22 14:30:31 2015
From: report at bugs.python.org (aruseni)
Date: Thu, 22 Jan 2015 13:30:31 +0000
Subject: [docs] [issue23294] A typo in the tutorial
In-Reply-To: <1421879644.03.0.144985173362.issue23294@psf.upfronthosting.co.za>
Message-ID: <1421933431.38.0.416887838353.issue23294@psf.upfronthosting.co.za>


aruseni added the comment:

@Eric You?re right. I thought it should be ?was? instead of ?is?, but it?s actually OK.

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

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

From report at bugs.python.org  Thu Jan 22 16:43:40 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Jan 2015 15:43:40 +0000
Subject: [docs] [issue23299] Documentation correction - 5.1.4. List
	Comprehensions
In-Reply-To: <1421916821.61.0.582688428376.issue23299@psf.upfronthosting.co.za>
Message-ID: <1421941420.37.0.6573240614.issue23299@psf.upfronthosting.co.za>


R. David Murray added the comment:

vec has not been changed.  The example is correct.  Give it a try :)

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

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

From report at bugs.python.org  Fri Jan 23 00:30:20 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 22 Jan 2015 23:30:20 +0000
Subject: [docs] [issue23294] A typo in the tutorial
In-Reply-To: <1421879644.03.0.144985173362.issue23294@psf.upfronthosting.co.za>
Message-ID: <1421969420.84.0.210210931982.issue23294@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

No problem! Thanks for looking at the documentation with an inquisitive eye.

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

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

From report at bugs.python.org  Fri Jan 23 02:30:22 2015
From: report at bugs.python.org (Liang Zhang)
Date: Fri, 23 Jan 2015 01:30:22 +0000
Subject: [docs] [issue23299] Documentation correction - 5.1.4. List
	Comprehensions
In-Reply-To: <1421916821.61.0.582688428376.issue23299@psf.upfronthosting.co.za>
Message-ID: <1421976622.59.0.289100807072.issue23299@psf.upfronthosting.co.za>


Liang Zhang added the comment:

Oh my god! You're right!

----------

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

From report at bugs.python.org  Sat Jan 24 03:41:40 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 24 Jan 2015 02:41:40 +0000
Subject: [docs] [issue23292] Enum doc suggestion
In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>
Message-ID: <1422067300.58.0.303835573631.issue23292@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Currently the way to add an Enum's members to a module's namespace is:

  globals().update(MyEnumeration.__members__)

but that seems quite ugly.  Is there anywhere else that the user is required to use __xxx__ methods for common functionality?

I think a new method, export_to(), would solve the problem much more nicely:

  @classmethod
  def export_to(cls, namespace):
      try:
          # assume a dict-like namespace
          namespace.update(cls.__members__)
      except AttributeError:
          # or an object-like namespace
          for name, member in cls.__members__.items():
              setattr(namespace, name, member)

----------
nosy: +barry, eli.bendersky

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

From report at bugs.python.org  Sat Jan 24 08:06:57 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Jan 2015 07:06:57 +0000
Subject: [docs] [issue23292] Enum doc suggestion
In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>
Message-ID: <1422083216.97.0.695894136742.issue23292@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Well, for such operations (namespace manipulation) __dict__ is also often used, so I wouldn't say it's too ugly.

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

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

From report at bugs.python.org  Sat Jan 24 12:02:00 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Jan 2015 11:02:00 +0000
Subject: [docs] [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1422097320.7.0.940954678485.issue4395@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

While Martin's patch doesn't cover all the vagaries of comparison operations discussed above, it fixes the outright error, and provides an appropriate cross-reference to functools.total_ordering.

----------

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

From report at bugs.python.org  Sat Jan 24 12:17:09 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Jan 2015 11:17:09 +0000
Subject: [docs] [issue23232] 'codecs' module functionality + its docs --
	concerning	custom codecs, especially non-string ones
In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za>
Message-ID: <1422098228.95.0.940990368647.issue23232@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Unfortunately, a lot of these things aren't well defined in the docs because they're not especially well defined, period. The codecs module works very well if you stick to the common, well-tested paths (primarily the text encodings), but it's complex enough that there are quite a few dark corners as well.

The functional changes in 3.4 and Martin's documentation updates in issue 19548 certainly improved things a bit further.

I'm inclined to agree with Marc-Andre's comment on 20132, that we're a bit down in the weeds at the moment, without a clear shared vision of where we *want* to be for the codecs module. A couple of other big issues with the current design of the module are the fact you can't register a codec directly, you have to register a search function (which you then can't unregister) and the fact that the "is a text encoding" flag I added for 3.4 is private, rather than a generally available capability.

In terms of this issue, until Martin's last patch, the error handling documentation basically all assumed text codecs. The changes in that patch clarified some areas that could be tested with the bytes-bytes codecs, but left others still vague because it isn't clear what's intended behaviour, and what's an implementation accident in CPython.

I've added MAL to the nosy list here as well, since if anyone is going to know the *intended* interaction between error handlers and arbitrary codecs its MAL.

----------
nosy: +lemburg

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

From report at bugs.python.org  Sat Jan 24 12:20:18 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Jan 2015 11:20:18 +0000
Subject: [docs] [issue23232] 'codecs' module functionality + its docs --
	concerning	custom codecs, especially non-string ones
In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za>
Message-ID: <1422098418.06.0.829034856725.issue23232@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Regarding the 6 vs 4 interfaces, what's really needed there is a clearer explanation of what functionality depends on each of the three interfaces (basic, stream, incremental), so that a codec developer has a clearer understanding of what won't work if they don't provide a particular interface.

----------

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

From report at bugs.python.org  Sat Jan 24 13:23:33 2015
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 24 Jan 2015 12:23:33 +0000
Subject: [docs] [issue23292] Enum doc suggestion
In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>
Message-ID: <1422102213.55.0.7855149694.issue23292@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I'm not sure why the current situation is annoying?

Python explicitly does not pollute the enclosing namespace with an Enum's members. So when you:

import A

It's fairly natural that you have access to A.MyEnum and not its members, no? Some modules (like some stdlib modules) may choose to push the enum members up to the module's scope explicitly, but I wouldn't necessarily call it best practice. Namespacing is Pythonic, splashing contents of classes into enclosing namespaces isn't.

So I guess what I'm trying to say is that I don't see a reason to explicitly suggest something that is, in general, against the spirit of Python, in the documentation.

[P.S. Thanks for reporting, Mark, I love your books!]

----------

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

From report at bugs.python.org  Sat Jan 24 13:40:46 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Jan 2015 12:40:46 +0000
Subject: [docs] [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1422103246.05.0.874048467624.issue4395@psf.upfronthosting.co.za>


Martin Panter added the comment:

The reference to @functools.total_ordering was actually already there; I just moved it into the paragraph about relationships between the operators. I should also point out that my description of the default __ne__() assumes that Issue 21408 is resolved; the current behaviour is slightly different.

If you think something else could be added to the patch, I?m happy to try and add it. Perhaps the default object.__eq__() behaviour?

----------

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

From report at bugs.python.org  Sat Jan 24 13:48:06 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Jan 2015 12:48:06 +0000
Subject: [docs] [issue23292] Enum doc suggestion
In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>
Message-ID: <1422103686.9.0.894835555922.issue23292@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I disagree. I assume that many new enums will be a replacement for module-level constants, but these still have to be available on the module. Keeping backward compatibility is not against the spirit of Python :)

----------

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

From report at bugs.python.org  Sat Jan 24 14:02:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Jan 2015 13:02:43 +0000
Subject: [docs] [issue23292] Enum doc suggestion
In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>
Message-ID: <1422104563.48.0.634533043144.issue23292@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agree with Eli.

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

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

From report at bugs.python.org  Sat Jan 24 18:40:01 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 24 Jan 2015 17:40:01 +0000
Subject: [docs] [issue23311] Update PC/example_nt and extending/windows.rst
Message-ID: <1422121201.94.0.918332856849.issue23311@psf.upfronthosting.co.za>


New submission from Steve Dower:

The installer for 3.5 will include an option to install debug binaries alongside the release ones, so we should update extending/windows.rst to explain that and generally describe how to build an extension. It should also refer to python3.dll at least once...

The example project in PC/example_nt is fairly outdated. It could be updated to automatically find a 3.5 install and use the debug or release binaries/libraries from there.

We could also include a 'test' project for PTVS (http://pytools.codeplex.com/) that helps write Python code for testing the extension and also has mixed-mode debugging enabled so people can step between the Python and the C code.

(In fact, the PTVS team wants to do a sample project like this anyway, so maybe we can remove PC/example_nt and point to theirs...)

----------
assignee: docs at python
components: Documentation, Windows
messages: 234624
nosy: docs at python, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Update PC/example_nt and extending/windows.rst
versions: Python 3.5

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

From report at bugs.python.org  Sat Jan 24 18:42:05 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 Jan 2015 17:42:05 +0000
Subject: [docs] [issue23312] google thinks the docs are mobile unfriendly
Message-ID: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

According to Google webmaster tools, the documentation has the following failings on mobile devices:

- The font size is too small. https://developers.google.com/speed/docs/insights/UseLegibleFontSizes
- The viewport is not configured.
- Touch controls are too close together.

You can look at the complaints on (for example) https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fdocs.python.org%2F3%2Flibrary%2Ffunctions.html

----------
assignee: docs at python
components: Documentation
messages: 234625
nosy: benjamin.peterson, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: google thinks the docs are mobile unfriendly
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jan 24 18:44:24 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 24 Jan 2015 17:44:24 +0000
Subject: [docs] [issue23311] Update PC/example_nt and extending/windows.rst
In-Reply-To: <1422121201.94.0.918332856849.issue23311@psf.upfronthosting.co.za>
Message-ID: <1422121464.09.0.180740186158.issue23311@psf.upfronthosting.co.za>


Steve Dower added the comment:

This is probably also a good place to refer to the changes in #22980 and how they can help when building extensions outside of distutils.

----------

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

From report at bugs.python.org  Sat Jan 24 18:58:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Jan 2015 17:58:34 +0000
Subject: [docs] [issue23312] google thinks the docs are mobile unfriendly
In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za>
Message-ID: <1422122314.63.0.591673394337.issue23312@psf.upfronthosting.co.za>


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


----------
nosy: +georg.brandl, serhiy.storchaka
versions:  -Python 3.6

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

From report at bugs.python.org  Sat Jan 24 19:07:25 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 24 Jan 2015 18:07:25 +0000
Subject: [docs] [issue23311] Update PC/example_nt and extending/windows.rst
In-Reply-To: <1422121201.94.0.918332856849.issue23311@psf.upfronthosting.co.za>
Message-ID: <1422122845.02.0.524126999589.issue23311@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jan 24 19:19:09 2015
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 24 Jan 2015 18:19:09 +0000
Subject: [docs] [issue23292] Enum doc suggestion
In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>
Message-ID: <1422123549.04.0.447063856007.issue23292@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Georg, each library writer is entitled to do whatever she wants. Naturally, we can't prevent dumping contents of enums into the module namespaces, and yes, backwards compatibility makes sense for some modules.

However, that's tangential to *encouraging* this un-Pythonic behavior by including the trick in the official documentation. After all, namespaces is a good idea (from the Zen of Python), and Enums as namespaces are also a good idea (self-documenting code).

There's a huge amount of tricks we could add to the documentation, but we don't. There's wikis for that, blogs, Stack Overflow, Active Python recipes, what have you.

I wouldn't spend too much time arguing about this, though. If you feel strongly that this belongs in the standard documentation, go ahead. I just wanted to provide an alternative view of the issue.

----------

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

From report at bugs.python.org  Sat Jan 24 20:25:07 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Jan 2015 19:25:07 +0000
Subject: [docs] [issue23292] Enum doc suggestion
In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>
Message-ID: <1422127507.79.0.353585453053.issue23292@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Likewise, I don't feel strongly that it *should* go in, but I wouldn't object to it.

----------

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

From report at bugs.python.org  Sat Jan 24 20:27:57 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Jan 2015 19:27:57 +0000
Subject: [docs] [issue23312] google thinks the docs are mobile unfriendly
In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za>
Message-ID: <1422127677.31.0.533887776094.issue23312@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Yes, the theme is anything but "responsive".  If someone already knows how to do this, please step forward.

I guess it's not too hard to move the sidebar to the top/bottom on mobile, and adapt the font sizes.

----------

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

From report at bugs.python.org  Sat Jan 24 20:40:18 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 24 Jan 2015 19:40:18 +0000
Subject: [docs] [issue23312] google thinks the docs are mobile unfriendly
In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za>
Message-ID: <1422128418.21.0.0200334630321.issue23312@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jan 25 02:01:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 25 Jan 2015 01:01:49 +0000
Subject: [docs] [issue23232] 'codecs' module functionality + its docs --
	concerning	custom codecs, especially non-string ones
In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za>
Message-ID: <1422147709.68.0.952643033224.issue23232@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am certainly no expert, but this is how I understand the three different kinds of codecs are used:

* Stateless codecs: str.encode(), bytes.decode(), etc
* Incremental codecs: TextIOWrapper, IncrementalNewlineDecoder
* Stream codecs: only stuff inside the ?codecs? module as far as I know: codecs.open(), EncodedFile() etc.

----------

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

From report at bugs.python.org  Sun Jan 25 06:00:02 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 25 Jan 2015 05:00:02 +0000
Subject: [docs] [issue21279] str.translate documentation incomplete
In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za>
Message-ID: <1422162002.1.0.512133569611.issue21279@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m happy with the new wording in v5. Maybe the docstring in the C module could be reflowed though.

----------

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

From report at bugs.python.org  Sun Jan 25 11:13:01 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 25 Jan 2015 10:13:01 +0000
Subject: [docs] [issue23312] google thinks the docs are mobile unfriendly
In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za>
Message-ID: <1422180781.49.0.47028834143.issue23312@psf.upfronthosting.co.za>


Georg Brandl added the comment:

There is already an enhanced theme: https://github.com/ionelmc/sphinx-py3doc-enhanced-theme

I will have a look at it.

----------

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

From report at bugs.python.org  Sun Jan 25 11:52:48 2015
From: report at bugs.python.org (Akira Li)
Date: Sun, 25 Jan 2015 10:52:48 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1422183167.91.0.87198789357.issue23251@psf.upfronthosting.co.za>


Akira Li added the comment:

I've removed mentioning of GIL and uploaded a new patch.

----------
Added file: http://bugs.python.org/file37850/docs-time.sleep-other-threads-are-not-blocked-2.diff

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

From report at bugs.python.org  Sun Jan 25 11:59:27 2015
From: report at bugs.python.org (Mark Summerfield)
Date: Sun, 25 Jan 2015 10:59:27 +0000
Subject: [docs] [issue23292] Enum doc suggestion
In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>
Message-ID: <1422183567.49.0.226354366351.issue23292@psf.upfronthosting.co.za>


Mark Summerfield added the comment:

Since this is a bit controversial, I've tried marking it as 'rejected' with this comment.

I've also added a very brief explanation and link back to here on my web site: http://www.qtrac.eu/pyenum.html

----------
resolution:  -> rejected

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

From report at bugs.python.org  Sun Jan 25 11:59:42 2015
From: report at bugs.python.org (Mark Summerfield)
Date: Sun, 25 Jan 2015 10:59:42 +0000
Subject: [docs] [issue23292] Enum doc suggestion
In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>
Message-ID: <1422183582.24.0.227177741039.issue23292@psf.upfronthosting.co.za>


Changes by Mark Summerfield <mark at qtrac.eu>:


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

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

From report at bugs.python.org  Sun Jan 25 13:32:07 2015
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Sun, 25 Jan 2015 12:32:07 +0000
Subject: [docs] [issue23312] google thinks the docs are mobile unfriendly
In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za>
Message-ID: <1422189127.47.0.204145594579.issue23312@psf.upfronthosting.co.za>


Maries Ionel Cristian added the comment:

You can see that theme in action at http://python-aspectlib.readthedocs.org/en/latest/

----------
nosy: +ionel.mc

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

From report at bugs.python.org  Sun Jan 25 14:10:17 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 25 Jan 2015 13:10:17 +0000
Subject: [docs] [issue23312] google thinks the docs are mobile unfriendly
In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za>
Message-ID: <1422191417.8.0.694604018345.issue23312@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Are you ok with us copying parts of the enhancements?

----------

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

From report at bugs.python.org  Sun Jan 25 14:17:44 2015
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Sun, 25 Jan 2015 13:17:44 +0000
Subject: [docs] [issue23312] google thinks the docs are mobile unfriendly
In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za>
Message-ID: <1422191864.62.0.428871068181.issue23312@psf.upfronthosting.co.za>


Maries Ionel Cristian added the comment:

Sure, take anything you want.

----------

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

From report at bugs.python.org  Sun Jan 25 16:43:00 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 25 Jan 2015 15:43:00 +0000
Subject: [docs] [issue23292] Enum doc suggestion
In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>
Message-ID: <1422200580.36.0.593780380671.issue23292@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Amusingly enough, I posted a question/answer to StackOverflow (http://stackoverflow.com/q/28130683/208880) and so far the only other respondent posted an answer with similar functionality to my own, and also recommended that such a method be added to the base Enum class.

----------

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

From report at bugs.python.org  Sun Jan 25 17:39:34 2015
From: report at bugs.python.org (John Posner)
Date: Sun, 25 Jan 2015 16:39:34 +0000
Subject: [docs] [issue21279] str.translate documentation incomplete
In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za>
Message-ID: <1422203974.52.0.482881229839.issue21279@psf.upfronthosting.co.za>


John Posner added the comment:

Per Martin's suggestion, deltas from issue21279.v5.patch:

* no change to patch for doc/library/stdtypes.rst

* doc string reflowed in patch for objects/unicodeobject.c

----------
Added file: http://bugs.python.org/file37855/issue21279.v6.patch

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

From report at bugs.python.org  Sun Jan 25 18:16:03 2015
From: report at bugs.python.org (Justin Eldridge)
Date: Sun, 25 Jan 2015 17:16:03 +0000
Subject: [docs] [issue23317] Incorrect description of descriptor invocation
	in Python	Language Reference
Message-ID: <1422206163.24.0.274216799196.issue23317@psf.upfronthosting.co.za>


New submission from Justin Eldridge:

The section titled "Invoking Descriptors" in the Python Language Reference [1]
says:

    Class Binding
        If binding to a new-style class, A.x is transformed into the call: 
        A.__dict__['x'].__get__(None, A).

This suggests that __get__ is looked up on the instance of x, when I believe
that it is actually looked up on the type. That is, it's my understanding that
A.x invokes:

    type(A.__dict__['x']).__get__(A.__dict__['x'], None, Foo))

Here's some Python 3.4 code demonstrating this:

    class A:
        pass

    class Descriptor:
        def __get__(self, obj, cls):
            print("Getting!")
            
    A.x = Descriptor()

    def replacement_get(obj, cls):
        print("This is a replacement.")
        
    A.__dict__['x'].__get__ = replacement_get

Now, writing:

    >>> A.x
    Getting!

    >>> A.__dict__['x'].__get__(None, A)
    This is a replacement!

    >>> type(A.__dict__['x']).__get__(A.__dict__['x'], None, A)
    Getting!

The documentation makes a similar statement about instance binding that also
appears to be incorrect. This is the case in all versions of the document I
could find.

What I believe to be the actual behavior is implied by a later section in the
same document, which states that the implicit invocation of special methods is
only guaranteed to work correctly if the special method is defined on the type,
not the instance.  This suggests that the statements in "Invoking Descriptors"
aren't quite correct, and while the true behavior is a little more verbose, I
think it would be worthwhile to update the documentation so as to avoid
confusion.

[1]: https://docs.python.org/2/reference/datamodel.html#invoking-descriptors

----------
assignee: docs at python
components: Documentation
messages: 234676
nosy: Justin.Eldridge, docs at python
priority: normal
severity: normal
status: open
title: Incorrect description of descriptor invocation in Python Language Reference
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/issue23317>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:54:08 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 25 Jan 2015 19:54:08 +0000
Subject: [docs] [issue21279] str.translate documentation incomplete
In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za>
Message-ID: <1422215648.84.0.960731887141.issue21279@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jan 25 21:28:10 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 25 Jan 2015 20:28:10 +0000
Subject: [docs] [issue23317] Incorrect description of descriptor invocation
	in Python	Language Reference
In-Reply-To: <1422206163.24.0.274216799196.issue23317@psf.upfronthosting.co.za>
Message-ID: <1422217690.54.0.82660210641.issue23317@psf.upfronthosting.co.za>


R. David Murray added the comment:

I believe that you are correct: special methods are looked up on the type, and this is assumed implicitly in the Class Binding description. (This was not 100% true in python2, but it is in current python3.)  But the Class Binding description is correct, since if the __get__ method is *not* defined on the type (of the descriptor), the descriptor instance itself is returned (so explicitly calling type in the "equivalent expression" would be wrong).

This is one of the most complex topics to describe in Python (I still don't have it solid in my head and I've been working with Python for years now).  If we can come up with clearer wording that is good, but we've tried several times already to improve it :(

I don't know what you are referring to for the 'instance binding' that makes the same 'mistake', but I suspect it is also covered by the "special methods are looked up on the type" rule.

----------
nosy: +r.david.murray
versions:  -Python 3.2, Python 3.3, Python 3.6

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

From report at bugs.python.org  Sun Jan 25 21:49:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Jan 2015 20:49:58 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <20150125204944.84277.39555@psf.io>


Roundup Robot added the comment:

New changeset 55ad65c4f9e2 by R David Murray in branch '3.4':
#23251: Note that time.sleep affects the calling thread only.
https://hg.python.org/cpython/rev/55ad65c4f9e2

New changeset 5e01c68cabbf by R David Murray in branch '2.7':
#23251: note that time.sleep affects the current thread only.
https://hg.python.org/cpython/rev/5e01c68cabbf

New changeset 5db28a3199b2 by R David Murray in branch '2.7':
#23251: Reflow paragraph.
https://hg.python.org/cpython/rev/5db28a3199b2

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

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

From report at bugs.python.org  Sun Jan 25 21:51:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 25 Jan 2015 20:51:27 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1422219087.72.0.711004992335.issue23251@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oops, typoed the issue number.

New changeset 3a9b1e5fe179 by R David Murray in branch '3.4':
#23215: reflow paragraph.
https://hg.python.org/cpython/rev/3a9b1e5fe179

New changeset 52a06812d5da by R David Murray in branch 'default':
Merge: #23215: note that time.sleep affects the current thread only.
https://hg.python.org/cpython/rev/52a06812d5da

----------

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

From report at bugs.python.org  Sun Jan 25 21:52:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 25 Jan 2015 20:52:51 +0000
Subject: [docs] [issue23251] mention in time.sleep() docs that it does not
	block	other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1422219171.0.0.396869033874.issue23251@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Akira, but I did not use your patch, since it still had the paragraph reflow in it.

----------
resolution:  -> fixed
stage: commit review -> resolved

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

From report at bugs.python.org  Sun Jan 25 23:15:47 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 25 Jan 2015 22:15:47 +0000
Subject: [docs] [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1422224147.16.0.359155365727.issue4395@psf.upfronthosting.co.za>


Martin Panter added the comment:

Adding a new patch that just fixes the typo error in the first patch

----------
Added file: http://bugs.python.org/file37859/default-ne-reflected-priority.v2.patch

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

From report at bugs.python.org  Mon Jan 26 08:31:17 2015
From: report at bugs.python.org (Devin Jeanpierre)
Date: Mon, 26 Jan 2015 07:31:17 +0000
Subject: [docs] [issue23322] parser module docs missing second example
Message-ID: <1422257477.04.0.712021667077.issue23322@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre:

The port to reST missed the second example: https://docs.python.org/release/2.5/lib/node867.html

This is still referred to in the docs, so it is not deliberate. For example, the token module docs say "The second example for the parser module shows how to use the symbol module": https://docs.python.org/3.5/library/token.html#module-token

There is no second example, nor any use of the symbol module, in the docs: https://docs.python.org/3.5/library/parser.html

----------
assignee: docs at python
components: Documentation
messages: 234716
nosy: Devin Jeanpierre, docs at python
priority: normal
severity: normal
status: open
title: parser module docs missing second example
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jan 26 09:03:38 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 26 Jan 2015 08:03:38 +0000
Subject: [docs] [issue23322] parser module docs missing second example
In-Reply-To: <1422257477.04.0.712021667077.issue23322@psf.upfronthosting.co.za>
Message-ID: <1422259418.13.0.0973173438073.issue23322@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The second example was removed in https://hg.python.org/cpython/rev/19ca70b463c5 It would be better to just update the "see also" note in the token documentation.

----------
keywords: +easy
nosy: +berker.peksag
stage:  -> needs patch
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jan 26 09:36:45 2015
From: report at bugs.python.org (Mark Summerfield)
Date: Mon, 26 Jan 2015 08:36:45 +0000
Subject: [docs] [issue23292] Enum doc suggestion
In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za>
Message-ID: <1422261405.91.0.950821966976.issue23292@psf.upfronthosting.co.za>


Mark Summerfield added the comment:

Nice answer Ethan (but I can't vote you up since stack overflow won't let me vote or even comment anymore).

As for adding export_to(), it seems like a good idea. However, personally, I think the signature should be

    hoist_into(namespace, cls, *clses)

to allow multiple enums in the same module to be exported in one go. (Just kidding about the new name though.)

PS I should have said earlier, thanks Eli:-)

----------

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

From report at bugs.python.org  Mon Jan 26 11:15:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Jan 2015 10:15:36 +0000
Subject: [docs] [issue18518] return-ing within code timed with timeit.timeit
	causes	wrong return value of timeit.timeit
In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za>
Message-ID: <20150126101523.87135.3001@psf.io>


Roundup Robot added the comment:

New changeset e8db1cbe416b by Serhiy Storchaka in branch '2.7':
Issue #18518: timeit now rejects statements which can't be compiled outside
https://hg.python.org/cpython/rev/e8db1cbe416b

New changeset a5769fa55791 by Serhiy Storchaka in branch '3.4':
Issue #18518: timeit now rejects statements which can't be compiled outside
https://hg.python.org/cpython/rev/a5769fa55791

New changeset b0a686260b5d by Serhiy Storchaka in branch 'default':
Issue #18518: timeit now rejects statements which can't be compiled outside
https://hg.python.org/cpython/rev/b0a686260b5d

----------

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

From report at bugs.python.org  Mon Jan 26 11:54:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Jan 2015 10:54:57 +0000
Subject: [docs] [issue18518] return-ing within code timed with timeit.timeit
	causes	wrong return value of timeit.timeit
In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za>
Message-ID: <1422269697.18.0.19221809453.issue18518@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Buildbots are unhappy. Example:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%202.7/builds/837/steps/test/logs/stdio

1 test failed:
    test_timeit

Re-running test 'test_timeit' in verbose mode
test test_timeit crashed -- <type 'exceptions.ImportError'>: No module named support
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 901, in runtest_inner
  File "/usr/home/buildbot/python/2.7.koobs-freebsd10/build/Lib/test/test_timeit.py", line 8, in <module>
    from test.support import run_unittest
ImportError: No module named support
[44296 refs]
*** Error code 1

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

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

From report at bugs.python.org  Mon Jan 26 12:13:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Jan 2015 11:13:11 +0000
Subject: [docs] [issue18518] return-ing within code timed with timeit.timeit
	causes	wrong return value of timeit.timeit
In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za>
Message-ID: <1422270791.7.0.0872298987954.issue18518@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Already fixed in 617c226da195. Needs time for buildbots to rerun tests. I didn't noticed error when backported tests because there was local file support.py in my workspace.

----------

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

From report at bugs.python.org  Mon Jan 26 15:04:31 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Jan 2015 14:04:31 +0000
Subject: [docs] [issue23323] Issue with imaplib and append messages passing
	a tuple	with flags
In-Reply-To: <1422276063.41.0.625016569735.issue23323@psf.upfronthosting.co.za>
Message-ID: <1422281071.39.0.801453776336.issue23323@psf.upfronthosting.co.za>


R. David Murray added the comment:

Indeed, as with much of the early email related code in the stdlib, the documentation assumes way too much familiarity with the relevant RFC...which is really hard to read.  We should add a few more details to the docs (like FLAGS being a string) even if we don't have the resources to do a full overhaul.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, r.david.murray
stage:  -> needs patch
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jan 26 18:54:08 2015
From: report at bugs.python.org (Justin Eldridge)
Date: Mon, 26 Jan 2015 17:54:08 +0000
Subject: [docs] [issue23317] Incorrect description of descriptor invocation
	in Python	Language Reference
In-Reply-To: <1422206163.24.0.274216799196.issue23317@psf.upfronthosting.co.za>
Message-ID: <1422294848.47.0.208362125773.issue23317@psf.upfronthosting.co.za>


Justin Eldridge added the comment:

Ah, I see how writing a description of this which is both concise and precise
would be difficult, especially for Python 2.

> But the Class Binding description is correct, since if the __get__ method is
> *not* defined on the type (of the descriptor), the descriptor instance itself
> is returned (so explicitly calling type in the "equivalent expression" would be
> wrong)

I see, but couldn't this also be held against the current "equivalent"?  That
is, saying A.x is equivalent to A.__dict__['x'].__get__(None, A) is not stricly
true when __get__ isn't defined on type(x).

I think I see now why this is difficult to document cleanly, and the "Special
method lookup" section of the documentation does a good job of explaining this.
The issue isn't exclusive to descriptors. It affects, for example, the
documentation on rich comparison operators, which says that x == y invokes
x.__eq__(y), when this hasn't quite been true since old-style classes.

So saying x == y is equivalent to x.__eq__(y) isn't really correct, and saying
that it is equivalent to type(x).__eq__(x,y) isn't quite right either, as
implicit invocation may bypass the metaclass's __getattribute__. The latter,
however, seems "less wrong". Is there a reason that the former is preferred by
the documentation?

----------

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

From report at bugs.python.org  Mon Jan 26 22:35:37 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Jan 2015 21:35:37 +0000
Subject: [docs] [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1422308137.67.0.603935879888.issue4395@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue23326.

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

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

From report at bugs.python.org  Tue Jan 27 01:53:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Jan 2015 00:53:06 +0000
Subject: [docs] [issue23286] A typo in the tutorial
In-Reply-To: <1421795362.32.0.373442891805.issue23286@psf.upfronthosting.co.za>
Message-ID: <20150127005227.74305.57204@psf.io>


Roundup Robot added the comment:

New changeset b3f0d7f50544 by Berker Peksag in branch '3.4':
Issue #23286: Fix typo in the tutorial.
https://hg.python.org/cpython/rev/b3f0d7f50544

New changeset 8cb151ff1575 by Berker Peksag in branch 'default':
Issue #23286: Fix typo in the tutorial.
https://hg.python.org/cpython/rev/8cb151ff1575

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

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

From report at bugs.python.org  Tue Jan 27 01:54:20 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 27 Jan 2015 00:54:20 +0000
Subject: [docs] [issue23286] A typo in the tutorial
In-Reply-To: <1421795362.32.0.373442891805.issue23286@psf.upfronthosting.co.za>
Message-ID: <1422320060.8.0.104779163181.issue23286@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed. Thanks for the patch!

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

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

From report at bugs.python.org  Tue Jan 27 03:19:11 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 27 Jan 2015 02:19:11 +0000
Subject: [docs] [issue22671] Typo in class io.BufferedIOBase docs
In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za>
Message-ID: <1422325151.93.0.599780059001.issue22671@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan 27 03:42:23 2015
From: report at bugs.python.org (Vipul Sharma)
Date: Tue, 27 Jan 2015 02:42:23 +0000
Subject: [docs] [issue23322] parser module docs missing second example
In-Reply-To: <1422257477.04.0.712021667077.issue23322@psf.upfronthosting.co.za>
Message-ID: <1422326543.02.0.360148051089.issue23322@psf.upfronthosting.co.za>


Vipul Sharma added the comment:

Can I work on this ? This would be my first contribution here also it looks good for a beginner

----------
nosy: +Vipul.Sharma

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

From report at bugs.python.org  Tue Jan 27 03:48:36 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 27 Jan 2015 02:48:36 +0000
Subject: [docs] [issue23322] parser module docs missing second example
In-Reply-To: <1422257477.04.0.712021667077.issue23322@psf.upfronthosting.co.za>
Message-ID: <1422326916.39.0.559039444298.issue23322@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Welcome, please go ahead and send a patch. Thanks!

----------

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

From report at bugs.python.org  Tue Jan 27 09:56:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Jan 2015 08:56:11 +0000
Subject: [docs] [issue18518] return-ing within code timed with timeit.timeit
	causes	wrong return value of timeit.timeit
In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za>
Message-ID: <1422348971.19.0.140150690087.issue18518@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan 27 13:30:53 2015
From: report at bugs.python.org (Vipul Sharma)
Date: Tue, 27 Jan 2015 12:30:53 +0000
Subject: [docs] [issue23322] parser module docs missing second example
In-Reply-To: <1422257477.04.0.712021667077.issue23322@psf.upfronthosting.co.za>
Message-ID: <1422361853.24.0.317438653434.issue23322@psf.upfronthosting.co.za>


Vipul Sharma added the comment:

Should I just remove the "See also" segment or just update its content like "See also: module parser.. Provides an interface to Python?s internal parser and byte-code compiler" ?

----------

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

From report at bugs.python.org  Tue Jan 27 17:02:42 2015
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 27 Jan 2015 16:02:42 +0000
Subject: [docs] [issue23232] 'codecs' module functionality + its docs --
	concerning	custom codecs, especially non-string ones
In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za>
Message-ID: <1422374562.78.0.603213357087.issue23232@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

That analysis seems correct to me.

Stateless and stream codecs were the original implementation. 2006 I implemented incremental codecs: http://bugs.python.org/issue1436130

The intent was to have stateful codecs that can work with iterators and generators.

When Guido began reimplementing the io machinery for Python 3 he used incremental codecs as the basis.

----------
nosy: +doerwalter

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

From roger at kistruck.co.uk  Thu Jan 22 10:53:27 2015
From: roger at kistruck.co.uk (Roger Kistruck)
Date: Thu, 22 Jan 2015 09:53:27 +0000
Subject: [docs] python-smbus and repeated starts
In-Reply-To: <CAKJDb-PdZkSc2TYmGp48-LDiBNL=+pkw9MYu_bCxz3n0uFGFmQ@mail.gmail.com>
References: <BBEF091A-E48A-4081-A232-493B3A9AAF0C@kistruck.co.uk>
 <CAKJDb-PdZkSc2TYmGp48-LDiBNL=+pkw9MYu_bCxz3n0uFGFmQ@mail.gmail.com>
Message-ID: <F4B39236-B1AB-40DA-81F3-F7313F3B97C7@kistruck.co.uk>

Hi Zach, 

On 22 Jan 2015, at 05:38, Zachary Ware wrote:

> This is not the appropriate venue for usage questions such as this;
> this list is meant for discussion of the Python documentation.  You'll
> have better luck asking on the main Python mailing list,

Thanks. Sorry to have bothered you. 

I'll try elsewhere. 

I _think_ I have now solved my problem by experiment and struggling with many other people's incoherent histories of their own struggles. It is "character-building" and all that, but a poor substitute for proper documentation! 

Roger

From ncoghlan at gmail.com  Sat Jan 24 12:00:51 2015
From: ncoghlan at gmail.com (ncoghlan at gmail.com)
Date: Sat, 24 Jan 2015 11:00:51 -0000
Subject: [docs] Document auto __ne__ generation;
 provide a use case for non-trivial __ne__ (issue 4395)
Message-ID: <20150124110051.5758.27524@psf.upfronthosting.co.za>

This looks like a good improvement to me, just one small typo.


http://bugs.python.org/review/4395/diff/13595/Doc/reference/datamodel.rst
File Doc/reference/datamodel.rst (right):

http://bugs.python.org/review/4395/diff/13595/Doc/reference/datamodel.rst#newcode1284
Doc/reference/datamodel.rst:1284: the left operand's method is has
priority.  Virtual subclassing is
s/is has/has/

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

From stefan.bollmann at rwth-aachen.de  Sun Jan 25 15:16:11 2015
From: stefan.bollmann at rwth-aachen.de (Stefan Bollmann)
Date: Sun, 25 Jan 2015 15:16:11 +0100
Subject: [docs] Embedding python in C
Message-ID: <21F0F526-78FE-4E51-AAA0-2AD154E8CC59@rwth-aachen.de>

Hi @all,

because of a question on stackoverflow (http://stackoverflow.com/questions/28128824/install-python-3-standard-library-on-raspberry-pi/28137230#28137230), I wondered about a difference between 2.7 and 3.2 Python C API. In https://docs.python.org/3.2/extending/embedding.html <https://docs.python.org/3.2/extending/embedding.html> there is an example in 5.1 to include Python code in c with a high level interface. However, there are problems regarding characters (wchar_t * vs. char *). Right now I do not have the solution (see stackoverflow post and links in my answer there), but there are differences between 2.7 and 3.2 API that are confusing.

Kind regards
Stefan Bollmann


? 

Stefan Bollmann
stefan.bollmann at rwth-aachen.de


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

From zachary.ware+pydocs at gmail.com  Wed Jan 28 20:08:12 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 28 Jan 2015 13:08:12 -0600
Subject: [docs] python-smbus and repeated starts
In-Reply-To: <F4B39236-B1AB-40DA-81F3-F7313F3B97C7@kistruck.co.uk>
References: <BBEF091A-E48A-4081-A232-493B3A9AAF0C@kistruck.co.uk>
 <CAKJDb-PdZkSc2TYmGp48-LDiBNL=+pkw9MYu_bCxz3n0uFGFmQ@mail.gmail.com>
 <F4B39236-B1AB-40DA-81F3-F7313F3B97C7@kistruck.co.uk>
Message-ID: <CAKJDb-PHeBW+OVNBZ9Fdc_w6EGsczqtyfmuuzNNgP-ttnf_MiA@mail.gmail.com>

On Thu, Jan 22, 2015 at 3:53 AM, Roger Kistruck <roger at kistruck.co.uk> wrote:
> Hi Zach,
>
> On 22 Jan 2015, at 05:38, Zachary Ware wrote:
>
>> This is not the appropriate venue for usage questions such as this;
>> this list is meant for discussion of the Python documentation.  You'll
>> have better luck asking on the main Python mailing list,
>
> Thanks. Sorry to have bothered you.

No problem.

> I'll try elsewhere.
>
> I _think_ I have now solved my problem by experiment and struggling with many other people's incoherent histories of their own struggles. It is "character-building" and all that, but a poor substitute for proper documentation!

Indeed.  You may want to bug the maintainers of python-smbus about
documenting their product, but as it is a third-party project it is
beyond the scope of this list (which is only concerned with the
documentation on docs.python.org; the Python Standard Library and
Language references).

I'm glad you've solved your problem!

Regards,
-- 
Zach

From report at bugs.python.org  Wed Jan 28 20:56:42 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 28 Jan 2015 19:56:42 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1422475002.22.0.172618352626.issue19980@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Ping.

----------

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

From richard.austin at hp.com  Wed Jan 28 20:46:24 2015
From: richard.austin at hp.com (Austin, Richard (CIP Fort Collins))
Date: Wed, 28 Jan 2015 19:46:24 +0000
Subject: [docs] Documentation bug
Message-ID: <5B28ECE5DDA11C4CB7742063DA498E8A25A57134@G2W2440.americas.hpqcorp.net>

On this page

https://docs.python.org/3.1/library/re.html

in section 7.2.6.1, the second sentence ends with 'and "1" through "9" representing the card with that value'.  Since the ace is represented by "a", I believe this should be 'and "2" through "9" representing the card with that value'.

This would also change the regular expression in the code excerpt immediately following.  I believe the first line should change to

valid = re.compile(r"[02-9akqj]{5}$")


Thanks!
Richard Austin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150128/5954353b/attachment-0001.html>

From zachary.ware+pydocs at gmail.com  Wed Jan 28 22:01:57 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 28 Jan 2015 15:01:57 -0600
Subject: [docs] Documentation bug
In-Reply-To: <5B28ECE5DDA11C4CB7742063DA498E8A25A57134@G2W2440.americas.hpqcorp.net>
References: <5B28ECE5DDA11C4CB7742063DA498E8A25A57134@G2W2440.americas.hpqcorp.net>
Message-ID: <CAKJDb-OJxpGUgtihnozqZdxSHgE-M33co2JpV0+6Fq3-NPHwDQ@mail.gmail.com>

Hi Richard,

On Wed, Jan 28, 2015 at 1:46 PM, Austin, Richard (CIP Fort Collins)
<richard.austin at hp.com> wrote:
> On this page
>
> https://docs.python.org/3.1/library/re.html
>
> in section 7.2.6.1, the second sentence ends with 'and ?1? through ?9?
> representing the card with that value'.  Since the ace is represented by
> "a", I believe this should be 'and ?2? through ?9? representing the card
> with that value'.
>
> This would also change the regular expression in the code excerpt
> immediately following.  I believe the first line should change to
>
> valid = re.compile(r"[02-9akqj]{5}$")

Thanks for the report!  However, this has already been fixed in more
recent versions of the documentation (see [1]) and versions before 3.4
are no longer receiving documentation updates.  If you're using Python
3.1 and can't upgrade to 3.4, you can still use the more recent
documentation; just watch out for "Changed in version ..." or "New in
version ..." notes for 3.2 or later.  If you come across something
that doesn't work with 3.1 and doesn't have a version changed or
version added note, that's a documentation bug that we do need to fix!

Regards,
-- 
Zach

[1] https://docs.python.org/3/library/re.html#checking-for-a-pair

From report at bugs.python.org  Wed Jan 28 23:20:44 2015
From: report at bugs.python.org (Hobs)
Date: Wed, 28 Jan 2015 22:20:44 +0000
Subject: [docs] [issue23343] operator precedence table for `not x` has an
	operand, while the others do not
Message-ID: <1422483644.76.0.913289618164.issue23343@psf.upfronthosting.co.za>


New submission from Hobs:

Shouldn't the [operator precedence table](https://docs.python.org/3.4/reference/expressions.html#operator-precedence), 5th row, 1st column, just say "`not`" rather than "`not` x"? The other rows are identified by the keyword for the operator and don't include any operand(s). Is there some other expression that includes `not` that should have a different position in the precedence table?

----------
assignee: docs at python
components: Documentation
messages: 234919
nosy: Hobson.Lane, docs at python
priority: normal
severity: normal
status: open
title: operator precedence table for `not x` has an operand, while the others do not
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jan 28 23:23:35 2015
From: report at bugs.python.org (Hobs)
Date: Wed, 28 Jan 2015 22:23:35 +0000
Subject: [docs] [issue23343] operator precedence table for `not x` has an
	operand, while the others do not
In-Reply-To: <1422483644.76.0.913289618164.issue23343@psf.upfronthosting.co.za>
Message-ID: <1422483815.1.0.601153801512.issue23343@psf.upfronthosting.co.za>


Hobs added the comment:

Just noticed the other entries for not. Not a bug.

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

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

From report at bugs.python.org  Wed Jan 28 23:44:02 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Jan 2015 22:44:02 +0000
Subject: [docs] [issue23343] operator precedence table for `not x` has an
	operand, while the others do not
In-Reply-To: <1422483644.76.0.913289618164.issue23343@psf.upfronthosting.co.za>
Message-ID: <1422485042.18.0.0656787906999.issue23343@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jan 29 04:59:05 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 29 Jan 2015 03:59:05 +0000
Subject: [docs] [issue22989] HTTPResponse.msg not as documented
In-Reply-To: <1417632317.82.0.906874710781.issue22989@psf.upfronthosting.co.za>
Message-ID: <1422503945.82.0.790204541729.issue22989@psf.upfronthosting.co.za>


Martin Panter added the comment:

Documenting the ?headers? attribute is also discussed in Issue 12707

----------

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

From report at bugs.python.org  Thu Jan 29 05:32:18 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 29 Jan 2015 04:32:18 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
	methods of	urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1422505938.1.0.798592940199.issue21228@psf.upfronthosting.co.za>


Martin Panter added the comment:

Related: Issue 12707, about deprecating some methods in favour of attributes

----------

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

From report at bugs.python.org  Thu Jan 29 17:42:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Jan 2015 16:42:09 +0000
Subject: [docs] [issue12743] C API marshalling doc contains XXX
In-Reply-To: <1313160183.82.0.137409262179.issue12743@psf.upfronthosting.co.za>
Message-ID: <1422549729.98.0.358147858201.issue12743@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan 30 00:07:57 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 29 Jan 2015 23:07:57 +0000
Subject: [docs] [issue18620] multiprocessing page leaves out important part
	of Pool	example
In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>
Message-ID: <1422572877.37.0.0094367111964.issue18620@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


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

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

From report at bugs.python.org  Fri Jan 30 07:41:09 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 30 Jan 2015 06:41:09 +0000
Subject: [docs] [issue13322] buffered read() and write() does not
	raise	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1422600069.59.0.617808361974.issue13322@psf.upfronthosting.co.za>


Martin Panter added the comment:

My experiments with buffered and unbuffered readers wrapping a non-blocking TCP socket, with no data received:

Method     Buffered impl.  Buffered doc.    SocketIO impl.  RawIOBase doc.
=========  ==============  ===============  ==============  ==============
read       None            BlockingIOError  None            None
read1      b""             [unclear]
readinto   None            BlockingIOError  None            None
readinto1  None            BlockingIOError
readall                                     None            [unclear]
peek       b""             [unclear]
readline   b""             [unspecified]    OSError         [unspecified]
readlines  []              [unspecified]    OSError         [unspecified]
__next__   StopIteration   [unspecified]    OSError         [unspecified]

The non-blocking behaviour of BufferedReader matches the RawIOBase documentation better than its own documentation. I?m not sure which way it should be fixed. Is this a documentation bug or an implementation bug?

I propose to change the read1() and peek() methods to behave like the others (whether than be returning None or raising BlockingIOError). It would be nice to have a way to differentiate non-blocking data being unavailable from hard EOF, at least for non-interactive mode, and the added consistency would be nice.

A non-blocking BufferedReader use case: to be able to peek one byte of a HTTP response stream to see if the connection has been closed. Plain sockets support MSG_PEEK, but SSL sockets don?t, and a BufferedReader is already being used. Later when actually parsing the response, the reader is set to blocking mode.

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

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

From report at bugs.python.org  Fri Jan 30 07:48:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 30 Jan 2015 06:48:55 +0000
Subject: [docs] [issue5811] io.BufferedReader.peek(): Documentation differs
	from	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1422600535.5.0.1609241341.issue5811@psf.upfronthosting.co.za>


Martin Panter added the comment:

The non-blocking behaviour that I documented in my patch is under question in Issue 13322. I think it would be nice change the implementation to either return None or raise BlockingIOError.

----------

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

From report at bugs.python.org  Sat Jan 31 01:39:04 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 31 Jan 2015 00:39:04 +0000
Subject: [docs] [issue20169] random module doc page has broken links
In-Reply-To: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za>
Message-ID: <1422664744.76.0.03847177669.issue20169@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sat Jan 31 01:57:02 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 31 Jan 2015 00:57:02 +0000
Subject: [docs] [issue17188] Document 'from None' in raise statement doc.
In-Reply-To: <1360631999.8.0.76627095073.issue17188@psf.upfronthosting.co.za>
Message-ID: <1422665822.24.0.59130807849.issue17188@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag
stage: needs patch -> patch review
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sat Jan 31 09:40:39 2015
From: report at bugs.python.org (py.user)
Date: Sat, 31 Jan 2015 08:40:39 +0000
Subject: [docs] [issue23356] In argparse docs simplify example about argline
Message-ID: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za>


New submission from py.user:

The example is:

def convert_arg_line_to_args(self, arg_line):
    for arg in arg_line.split():
        if not arg.strip():
            continue
        yield arg

str.split() with default delimiters never returns empty or whitespace strings in the list.

>>> '  x  x  '.split()
['x', 'x']
>>> '  '.split()
[]
>>>

Therefore, the if condition doesn't ever continue the loop.
It can be written:

def convert_arg_line_to_args(self, arg_line):
    for arg in arg_line.split():
        yield arg

It's the same as:

def convert_arg_line_to_args(self, arg_line):
    return iter(arg_line.split())

I guess, nothing uses next() for the result:

def convert_arg_line_to_args(self, arg_line):
    return arg_line.split()

Applied a patch with the last variant.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: args_ex_argline.diff
keywords: patch
messages: 235089
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In argparse docs simplify example about argline
type: performance
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file37934/args_ex_argline.diff

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

From report at bugs.python.org  Sat Jan 31 09:58:11 2015
From: report at bugs.python.org (py.user)
Date: Sat, 31 Jan 2015 08:58:11 +0000
Subject: [docs] [issue23356] In argparse docs simplify example about argline
In-Reply-To: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za>
Message-ID: <1422694690.48.0.0469123970958.issue23356@psf.upfronthosting.co.za>


py.user added the comment:

Url
https://docs.python.org/3/library/argparse.html#customizing-file-parsing

----------

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

From report at bugs.python.org  Sat Jan 31 13:26:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Jan 2015 12:26:07 +0000
Subject: [docs] [issue23254] Document how to close the TCPServer listening
	socket
In-Reply-To: <1421469175.0.0.628748486385.issue23254@psf.upfronthosting.co.za>
Message-ID: <1422707167.87.0.9031865125.issue23254@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a simple patch to add server_close() to the documentation, and a simple test to ensure it closes the socket.

----------
keywords: +patch
versions: +Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37940/server_close.patch

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

From Laura-M.Niesemann at web.de  Fri Jan 30 17:01:08 2015
From: Laura-M.Niesemann at web.de (Laura M Niesemann)
Date: Fri, 30 Jan 2015 17:01:08 +0100
Subject: [docs] Bug bei py2exe
Message-ID: <trinity-ff930e58-f76e-4f47-ab1f-cdac5f02b0fa-1422633668359@3capp-webde-bs04>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150130/6269799d/attachment.html>