From report at bugs.python.org  Sun Dec  1 00:03:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Nov 2013 23:03:25 +0000
Subject: [docs] [issue19845] Compiling Python on Windows docs
In-Reply-To: <1385844842.4.0.324477828597.issue19845@psf.upfronthosting.co.za>
Message-ID: <3dX7Rc3m6Gz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset a239897084bf by Zachary Ware in branch '3.3':
Issue #19845: Updated the Compiling Python on Windows docs.
http://hg.python.org/cpython/rev/a239897084bf

New changeset f4eedd29706b by Zachary Ware in branch 'default':
Issue #19845: Updated the Compiling Python on Windows docs.
http://hg.python.org/cpython/rev/f4eedd29706b

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

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

From report at bugs.python.org  Sun Dec  1 00:05:28 2013
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 30 Nov 2013 23:05:28 +0000
Subject: [docs] [issue19845] Compiling Python on Windows docs
In-Reply-To: <1385844842.4.0.324477828597.issue19845@psf.upfronthosting.co.za>
Message-ID: <1385852728.37.0.732389532996.issue19845@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the report; I could have sworn I had submitted a patch for this several months ago, but it seems like I didn't and had completely forgotten about it.

----------
assignee: docs at python -> zach.ware
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.3

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

From report at bugs.python.org  Sun Dec  1 03:16:18 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 01 Dec 2013 02:16:18 +0000
Subject: [docs] [issue19822] PEP process entrypoint
In-Reply-To: <1385647169.27.0.622120668783.issue19822@psf.upfronthosting.co.za>
Message-ID: <1385864178.72.0.811392287589.issue19822@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Sun Dec  1 12:37:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 11:37:43 +0000
Subject: [docs] [issue19849] selectors behaviour on EINTR undocumented
Message-ID: <1385897862.95.0.970282300769.issue19849@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Selector.Select() may return an empty list when interrupted, but the doc doesn't say so. The reader will probably trust the statement that """If timeout is None, the call will block until a monitored file object becomes ready""".

----------
assignee: docs at python
components: Documentation
messages: 204914
nosy: docs at python, neologix, pitrou
priority: normal
severity: normal
status: open
title: selectors behaviour on EINTR undocumented
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  1 13:16:04 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 12:16:04 +0000
Subject: [docs] [issue19849] selectors behaviour on EINTR undocumented
In-Reply-To: <1385897862.95.0.970282300769.issue19849@psf.upfronthosting.co.za>
Message-ID: <1385900164.11.0.385561137376.issue19849@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

How about this?

----------
keywords: +needs review, patch
stage:  -> patch review
Added file: http://bugs.python.org/file32924/selectors_select_signal.diff

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

From report at bugs.python.org  Sun Dec  1 13:20:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 12:20:12 +0000
Subject: [docs] [issue19849] selectors behaviour on EINTR undocumented
In-Reply-To: <1385897862.95.0.970282300769.issue19849@psf.upfronthosting.co.za>
Message-ID: <1385900412.54.0.355063703889.issue19849@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Looks good to me.

----------

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

From report at bugs.python.org  Sun Dec  1 13:31:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Dec 2013 12:31:30 +0000
Subject: [docs] [issue19849] selectors behaviour on EINTR undocumented
In-Reply-To: <1385897862.95.0.970282300769.issue19849@psf.upfronthosting.co.za>
Message-ID: <3dXTN14FPCz7Lk7@mail.python.org>


Roundup Robot added the comment:

New changeset b0c4c7f04f05 by Charles-Fran?ois Natali in branch 'default':
Issue #19849: selectors: Document the possibility of early select() wakeup upon
http://hg.python.org/cpython/rev/b0c4c7f04f05

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

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

From report at bugs.python.org  Sun Dec  1 13:37:01 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 12:37:01 +0000
Subject: [docs] [issue19849] selectors behaviour on EINTR undocumented
In-Reply-To: <1385897862.95.0.970282300769.issue19849@psf.upfronthosting.co.za>
Message-ID: <1385901421.28.0.929551731214.issue19849@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.2 -Python 3.4

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

From report at bugs.python.org  Sun Dec  1 16:39:43 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 01 Dec 2013 15:39:43 +0000
Subject: [docs] [issue10976] json.loads() raises TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1385912383.26.0.603339173108.issue10976@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Bike-shedding: instead of jsonb, make it json.bytes. Else, it may get confused with other protocols, such as "JSONP" or "BSON".

----------
nosy: +loewis

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

From report at bugs.python.org  Sun Dec  1 21:57:46 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 01 Dec 2013 20:57:46 +0000
Subject: [docs] [issue10976] json.loads() raises TypeError on bytes object
In-Reply-To: <1385912383.26.0.603339173108.issue10976@psf.upfronthosting.co.za>
Message-ID: <CADiSq7enVZO-exTcMQ_420TFFJdx=QPPrHTw-mt1j7=PoH8xmA@mail.gmail.com>


Nick Coghlan added the comment:

json.bytes would also work for me. It wouldn't need to replicate the full
main module API, just combine the text transform with UTF-8 encoding and
decoding (as well as autodetected UTF-16 and UTF-32 decoding) for the main
4 functions (dump[s], load[s]).

If people want UTF-16 and UTF-32 *en*coding (which seem to be rarely used
in combination with JSON), then they can invoke the text transform version
directly, and then do a separate encoding step.

----------

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

From report at bugs.python.org  Mon Dec  2 12:08:48 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 11:08:48 +0000
Subject: [docs] [issue16404] Uses of PyLong_FromLong that don't check for
	errors
In-Reply-To: <1352041027.23.0.922968343734.issue16404@psf.upfronthosting.co.za>
Message-ID: <1385982528.74.0.0148622972207.issue16404@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Dec  2 12:18:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 11:18:32 +0000
Subject: [docs] [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1385983112.0.0.768072005977.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I fixed the documentation, thanks for your report!

----------
assignee:  -> docs at python
components: +Documentation -IO
nosy: +docs at python
resolution:  -> fixed
status: open -> closed
versions: +Python 3.4

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

From report at bugs.python.org  Mon Dec  2 12:19:53 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 11:19:53 +0000
Subject: [docs] [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1385983193.03.0.350511467508.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Code in Python 3.4.

initfsencoding():
http://hg.python.org/cpython/file/e3c48bddf621/Python/pythonrun.c#l965

get_locale_encoding():
http://hg.python.org/cpython/file/e3c48bddf621/Python/pythonrun.c#l250

----------

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

From report at bugs.python.org  Mon Dec  2 12:28:38 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 02 Dec 2013 11:28:38 +0000
Subject: [docs] [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1385983718.92.0.36418796316.issue19847@psf.upfronthosting.co.za>


Sworddragon added the comment:

It is nice that you could fixed the documentation due to this report but this was just a sideeffect - so closing this report and moving it to "Documentation" was maybe wrong.

----------

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

From report at bugs.python.org  Mon Dec  2 12:42:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 11:42:12 +0000
Subject: [docs] [issue19833] asyncio: patches to document EventLoop and add
	more	examples
In-Reply-To: <1385738176.38.0.477367051955.issue19833@psf.upfronthosting.co.za>
Message-ID: <3dY4Dg60y5z7Lsh@mail.python.org>


Roundup Robot added the comment:

New changeset 7b4d046dbf56 by Victor Stinner in branch 'default':
Issue #19833: asyncio doc: add class name to methods
http://hg.python.org/cpython/rev/7b4d046dbf56

New changeset b25458022965 by Victor Stinner in branch 'default':
Issue #19833: add 2 examples to asyncio doc (hello world)
http://hg.python.org/cpython/rev/b25458022965

New changeset 5e4ea92f9a9b by Victor Stinner in branch 'default':
Issue #19833: Document more asyncio.BaseEventLoop methods
http://hg.python.org/cpython/rev/5e4ea92f9a9b

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

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

From report at bugs.python.org  Mon Dec  2 13:23:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 12:23:02 +0000
Subject: [docs] [issue19861] Update What's New for Python 3.4
Message-ID: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Many features and changes were not mentioned in What's New (especially added early). Here is main features which possible worth to mention:

abc:  The ABC class, the get_cache_token function.

aifc:  Any bytes-like objects are now accepted.

audioop:  Any bytes-like objects are now accepted.  Strings no more supported.

base64:  ascii85/base85 codecs.

bz2:  The 'x' mode.

codecs:  The cp1125 encoding.

collections:  New optional parameter in ChainMap.new_child().

dbm:  Support for the context management protocol.

dis:  Added the file parameter to many functions. Added the stack_effect() 
function.

email:  The policy keyword argument was added in email.message.Message 
constructor. The replace keyword argument was added in the set_param() 
method. 
The EmailPolicy.content_manager attribute was added 

filecmp:  Added the clear_cache() function and the dircmp.DEFAULT_IGNORES 
attribute.

functools:  total_ordering now supports the NotImplemented value.

gc:  Added the get_stats() function.

glob:  Added the escape() function.

gzip: The 'x' mode.

http:  HTTP 0.9-style "Simple Responses" are not supported. Added the explain 
argument in BaseHTTPRequestHandler.send_error(). Added the --bind option in 
the http.server module CLI.

ipaddress:  Added the IPv4Address.is_global attribute.

json:  Used ``(',', ': ')`` as default in dump() and dumps() if indent is not 
None. I.e. trailing spaces no more produced by default.

logging:  An instance of a subclass of RawConfigParser is now accepted as a 
value for fname in the fileConfig() function. The verify argument was added in 
the listen() function. The atTime parameter was added in 
TimedRotatingFileHandler constructor.  Added support of Unix domain sockets 
in SocketHandler and DatagramHandler.

lzma:  The 'x' mode.

multiprocessing:  Added following functions: get_all_start_methods(), 
get_context(), get_start_method(), and set_start_method(). set_executable() 
is now supported on Unix when the 'spawn' start method is used. Added the 
context parameter in Pool constructor.

operator:  Added the length_hint() function.

os.path:  samestat() now is supported on Windows.

os:  Add O_TMPFILE constant on Linux.

plistlib:  Added support for binary format. Added load(), loads(), dump(), and 
dumps() functions. Deprecated readPlist(), writePlist() readPlistFromBytes(), 
and writePlistToBytes() functions, the Data class.

select:  epoll() now supports the context management protocol. Added the 
close() and fileno() methods and the closed attribute in the devpoll class.

shelve:  Added context manager support.

shutil:  Added the SameFileError exception.

smtpd:  The map argument was added in SMTPServer constructor.

socket:  The CAN_BCM protocol was added. The AF_LINK family was added.

sqlite3:  Added support for URI.

subprocess: The input parameter was added in the check_output() function.

sunau:  Added support for 24-bit samples. Any bytes-like objects are now 
accepted.

sys:  Added the getallocatedblocks() function. Added the __interactivehook__ 
hook.

tarfile:  Added command-line interface.

textwrap:  Added support for truncating.

threading:  Added the main_thread() function.

unittest:  Added the TestCase.assertLogs() method. The TestSuite no more held 
references to each TestCase after TestSuite.run(). Modules that raise SkipTest 
on import are recorded as skips, not errors. Paths are sorted before being 
imported to ensure execution order for a given test suite is the same.

urllib:  Added the HTTPError.headers attribute. Added the Request.full_url 
attribute and the Request.remove_header() and Request.get_full_url() methods. 
Default Request.method may be indicated at the class level.

venv:  Added the ``with_pip`` parameter in EnvBuilder.

wave:  Any bytes-like objects are now accepted. Added support for unseekable 
files.

xml.etree.elementtree:  Added support to output empty elements in short form.

zipfile:  ZIP64 extensions are enabled by default.


Other enhancements:le.

memoryview is now registered automatically with collections.abc.Sequence.

Deprecations:

The 'U' mode in open() for file objects, in the fileinput and zipfile modules. A couple of plistlib functions. The html argument of XMLParser() and the parser argument of iterparse() in the xml.etree.elementtree module.

----------
assignee: docs at python
components: Documentation
messages: 205005
nosy: docs at python, larry, serhiy.storchaka
priority: release blocker
severity: normal
status: open
title: Update What's New for Python 3.4
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec  2 13:24:26 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 12:24:26 +0000
Subject: [docs] [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1385987066.37.0.6943147287.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

(Oops, I specified the wrong issue number in my commits.)

New changeset b231e0c3fd26 by Victor Stinner in branch '3.3':
Issue #19728: Fix sys.getfilesystemencoding() documentation
http://hg.python.org/cpython/rev/b231e0c3fd26

New changeset e3c48bddf621 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #19728: Fix sys.getfilesystemencoding() documentation
http://hg.python.org/cpython/rev/e3c48bddf621

----------

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

From report at bugs.python.org  Mon Dec  2 13:34:18 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 12:34:18 +0000
Subject: [docs] [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1385987658.05.0.749644891742.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"It is nice that you could fixed the documentation due to this report but this was just a sideeffect - so closing this report and moving it to "Documentation" was maybe wrong."

Oh sorry, I read the issue too quickly, I stopped at the first sentence. I reopen the issue the reply to the other points.


"In my opinion relying on the locale environment is risky since filesystem-encoding != locale. This is especially the case if working on a filesystem from an external media like an external hard disk drive. Operating on multiple media can also result in different filesystem-encodings."

This issue is not specific to Python. If you mount an USB key formated in VFAT with the wrong encoding on Linux, you will get mojibake in your file explorer. Same issue if you connect a network share (ex: NFS) using a different encoding than the server. You can find many other examples (hint: Mac OS X and Unicode normalization).

There is no good compromise here. The only two safe options are:

(A) convert filenames of your filesystem to the same encoding than your computer (there are tools for that, like convmv)

(B) use raw bytes instead of Unicode, Python 3 should accept bytes anywhere that OS data is expected (filenames, command line arguments, environment variables)

All operating systems (except Windows) are now using UTF-8 by default for the locale encoding. So slowly, mojibake issues on filename should become very rare.


"It would be useful if the user can make his own checks and change the default filesystem-encoding if needed."

This idea was already proposed in issue #8622, but it was a big fail. Please read my following email for more information:
https://mail.python.org/pipermail/python-dev/2010-October/104509.html

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

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

From report at bugs.python.org  Mon Dec  2 16:58:02 2013
From: report at bugs.python.org (Martijn Faassen)
Date: Mon, 02 Dec 2013 15:58:02 +0000
Subject: [docs] [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1385999882.4.0.920055878604.issue14787@psf.upfronthosting.co.za>


Martijn Faassen added the comment:

I just ran into this bug myself with namespace packages (in Python 2.7). When you have multiple packages (ns.a, ns.b) under a namespace package (ns), and constrain the paths in walk_packages so it should only pick up ns.a, it will pick up ns.b as well.

Any hope for a fix or workaround?

----------
nosy: +faassen

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

From report at bugs.python.org  Mon Dec  2 17:59:26 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 16:59:26 +0000
Subject: [docs] [issue19833] asyncio: patches to document EventLoop and add
	more	examples
In-Reply-To: <1385738176.38.0.477367051955.issue19833@psf.upfronthosting.co.za>
Message-ID: <1386003566.26.0.848155500307.issue19833@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I documented many new classes. I read the source code and copied classes to extract docstrings.

Instead of BaseXXX classes, it's maybe better to document AbstractXXX classes.

----------

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

From report at bugs.python.org  Mon Dec  2 19:57:53 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 02 Dec 2013 18:57:53 +0000
Subject: [docs] [issue19863] Missing function attributes in 2.7 docs.
Message-ID: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

The attached patch fills in some missing function attributes from the Python 2.7 datamodel docs.

----------
assignee: docs at python
components: Documentation
files: missing_function_attributes.patch
keywords: patch
messages: 205038
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: Missing function attributes in 2.7 docs.
versions: Python 2.7
Added file: http://bugs.python.org/file32938/missing_function_attributes.patch

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

From report at bugs.python.org  Mon Dec  2 20:00:54 2013
From: report at bugs.python.org (Max Polk)
Date: Mon, 02 Dec 2013 19:00:54 +0000
Subject: [docs] [issue19864] multiprocessing Proxy docs need locking
	semantics	explained
Message-ID: <1386010854.42.0.669130689835.issue19864@psf.upfronthosting.co.za>


New submission from Max Polk:

In the docs (both Python 2 and 3) for the multiprocessing module, the Proxy section needs to be explicit about the fact that is does NOT create locks around access to shared objects.

Why?  Because on the same page, we read about multiprocessing.managers.SyncManager's Queue method to create a shared queue.Queue object and return a proxy for it, next to other methods like SyncManager.list to create a "process safe" list.

But later, a willful violation of these semantics exists in the "Using a remote manager" section where a Proxy is implicitly created (via the register method of multiprocessing.managers.BaseManager) surrounding a Queue.Queue object.

Note that it did not create a proxy around a SyncManager.Queue, it created it around a Queue.Queue.  A user who copies this code and replaces Queue.Queue with a plain Python list gets the sense that all the needed locks will be created to protect the shared list.

However, due to lack of documentation in the Proxy section, the user will not know it's an unsafe list, and Proxy isn't helping them.  I'm guessing that Queue.Queue has its own locks to protect it in a process-shared setting, and we "lucked out" in this example, but an unwary reader's luck runs out if they replace it with a plain Python list.

Therefore, may I suggest two changes: (1) replace Queue.Queue with SyncManager.Queue in the "Using a remote manager" section to avoid misleading readers; and (2) be explicit in Proxy class docs that "no locks are created" to protect against concurrent access, and maybe add that the user must go to the multiprocessing.managers.SyncManager methods (Queue, list, etc) to get "process safe" objects to place behind the Proxy.

----------
assignee: docs at python
components: Documentation
messages: 205039
nosy: docs at python, maxpolk
priority: normal
severity: normal
status: open
title: multiprocessing Proxy docs need locking semantics explained

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

From report at bugs.python.org  Mon Dec  2 20:01:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 19:01:48 +0000
Subject: [docs] [issue19863] Missing function attributes in 2.7 docs.
In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>
Message-ID: <1386010908.87.0.0078776145484.issue19863@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps aliases should be added in same cell as original names?

       +-----------------------+-------------------------------+-----------+
       | :attr:`func_code`,    | The code object representing  | Writable  |
       | :attr:`__code__`      | the compiled function body.   |           |
       +-----------------------+-------------------------------+-----------+

Or add new "Alias" column?

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

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

From report at bugs.python.org  Mon Dec  2 20:23:55 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 02 Dec 2013 19:23:55 +0000
Subject: [docs] [issue19863] Missing function attributes in 2.7 docs.
In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>
Message-ID: <1386012235.09.0.747900385649.issue19863@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Perhaps aliases should be added in same cell as original names?

That sounds good to me.  Perhaps with a single explanatory line below the table to explain that the double-underscore variants were introduced for compatibility with Python 3.

----------

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

From report at bugs.python.org  Mon Dec  2 20:43:44 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 02 Dec 2013 19:43:44 +0000
Subject: [docs] [issue19863] Missing function attributes in 2.7 docs.
In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>
Message-ID: <1386013424.49.0.283427446468.issue19863@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Updated patch.

----------
Added file: http://bugs.python.org/file32939/missing_function_attributes_v2.patch

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

From report at bugs.python.org  Mon Dec  2 21:13:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 20:13:13 +0000
Subject: [docs] [issue19863] Missing function attributes in 2.7 docs.
In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>
Message-ID: <1386015193.39.0.530867470344.issue19863@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Then write the double-underscore variants at first place.

----------

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

From report at bugs.python.org  Mon Dec  2 22:49:42 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 02 Dec 2013 21:49:42 +0000
Subject: [docs] [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1386020982.3.0.960321395728.issue19847@psf.upfronthosting.co.za>


Sworddragon added the comment:

> This idea was already proposed in issue #8622, but it was a big fail.

Not completely: If your locale is utf-8 and you want to operate on an utf-8 filesystem all is fine. But what if you want then to operate on a ntfs (non-utf-8) partition? As I know there is no way to apply Python-environment variables on the fly with an effect to the interpreter. In my opinion this is the reason why a setter is needed here.

Otherwise the user has to go sure to use .encode() on all filesystem operations. Also he must ensure that .encode() doesn't throw any exception if the code must be robust. And with issue http://bugs.python.org/issue19846 this must likely be done with the content too. This will be really a hell in increasing the number of lines due to exception checking.

Is there a special reason that is against such a setter? The current advantage would be a huge increasing in maintainability of Python scripts who are relying on a high stability.

----------

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

From report at bugs.python.org  Mon Dec  2 22:54:00 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 02 Dec 2013 21:54:00 +0000
Subject: [docs] [issue19864] multiprocessing Proxy docs need locking
	semantics	explained
In-Reply-To: <1386010854.42.0.669130689835.issue19864@psf.upfronthosting.co.za>
Message-ID: <1386021240.87.0.365007756549.issue19864@psf.upfronthosting.co.za>


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


----------
nosy: +sbt
versions: +Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec  3 09:34:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 08:34:41 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386059681.09.0.513321627301.issue19871@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think it would be better to adhere to the JSON spec, which doesn't allow numbers to start with a decimal point:
http://json.org/

If we go this way, the documentation should at least be fixed; and, as you say, we could also add a unit test for it.

----------
assignee:  -> docs at python
components: +Documentation, Tests -Library (Lib)
nosy: +docs at python, pitrou
stage:  -> needs patch
versions:  -Python 3.5

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

From report at bugs.python.org  Tue Dec  3 09:34:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 08:34:53 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386059693.74.0.128657382206.issue19871@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

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

From report at bugs.python.org  Tue Dec  3 09:35:27 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 03 Dec 2013 08:35:27 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386059727.0.0.425824939173.issue19871@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/issue19871>
_______________________________________

From report at bugs.python.org  Tue Dec  3 10:18:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Dec 2013 09:18:23 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386062303.67.0.616083392312.issue19871@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agree with Antoine.

----------

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

From report at bugs.python.org  Tue Dec  3 13:32:59 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 03 Dec 2013 12:32:59 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386073979.52.0.652186486538.issue19871@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

In context, the doc is correct:

"""
parse_float, if specified, will be called with the string of every JSON float to be decoded. By default, this is equivalent to float(num_str).
"""

IIUC, parse_float only comes into play once the JSON source has already been tokenized, and the tokenization stage has already rejected things like '.5' by that point.  (The point of parse_float is that you can choose to turn numeric strings into decimal.Decimal instances instead of floats if you so wish.)

I agree it could use clarification.

----------

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

From report at bugs.python.org  Tue Dec  3 15:11:19 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 14:11:19 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
Message-ID: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I remember a discussion about EBADF, but I don't remember the conclusion. The documentation of the asyncio doesn't explain the behaviour of selectors when a file/socket is closed, without unregistering it from the selector.

I should be explicitly documented. I would accept an "undefined behaviour" if it's documented :-)

----------
assignee: docs at python
components: Documentation
messages: 205118
nosy: docs at python, gvanrossum, haypo, neologix
priority: normal
severity: normal
status: open
title: selectors (and asyncio?): document behaviour on closed files/sockets
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec  3 15:41:19 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 03 Dec 2013 14:41:19 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386081679.64.0.372281000811.issue19871@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

There are other forms of numbers allowed by Python that are not allowed by JSON: "001.1"

Oddly, with all of the strictness in JSON, the exponent-marker "e" can be upper- or lower-case:  1e1 and 1E1 are both valid JSON.

----------
nosy: +nedbat

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

From report at bugs.python.org  Tue Dec  3 16:42:44 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 03 Dec 2013 15:42:44 +0000
Subject: [docs] [issue19864] multiprocessing Proxy docs need locking
	semantics	explained
In-Reply-To: <1386010854.42.0.669130689835.issue19864@psf.upfronthosting.co.za>
Message-ID: <1386085364.77.0.484218607817.issue19864@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

>From what I remember a proxy method will be thread/process-safe if the referent's corresponding method is thread safe.

It should certainly be documented that the exposed methods of a proxied object should be thread-safe.

----------

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

From report at bugs.python.org  Tue Dec  3 16:45:37 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 15:45:37 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386085537.2.0.87673586993.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Yeah, the behavior is at least different for each type of polling system calls, and possibly also for different platforms.  It would be good to describe at least all the different possible behaviors.

----------

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

From report at bugs.python.org  Tue Dec  3 18:37:27 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 03 Dec 2013 17:37:27 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386092247.37.0.250552425203.issue19871@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Tue Dec  3 18:46:18 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 17:46:18 +0000
Subject: [docs] [issue19833] asyncio: patches to document EventLoop and add
	more	examples
In-Reply-To: <1385738176.38.0.477367051955.issue19833@psf.upfronthosting.co.za>
Message-ID: <1386092778.81.0.417355270283.issue19833@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Dec  3 19:30:04 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 03 Dec 2013 18:30:04 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386085537.2.0.87673586993.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM31iCe+iX2LKp8u0x59=Uc5jGdzsmdDcgX72YVaOP5D=w@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Well, unregister() documentation currently contains this:
"""
   .. method:: unregister(fileobj)

      Unregister a file object from selection, removing it from monitoring. A
      file object shall be unregistered prior to being closed.
"""

I'm not sure what else to say (I don' like the idea of documenting
possible behaviors, because it's non-portable, and really might change
in a future version).

----------

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

From report at bugs.python.org  Tue Dec  3 19:35:20 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 18:35:20 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386095720.42.0.0308162053189.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I think we should give the reader some kind of hint, since a bug in this area may cause a lot of pain when it has to be debugged on porting from a system where the issue is silent to one where it causes a crash.  These docs (unlike a PEP) are not a formal standard but documentation for users.  Maybe we can add a separate section of caveats?

----------

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

From report at bugs.python.org  Tue Dec  3 19:41:34 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 18:41:34 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386096094.41.0.681450874589.issue19876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"(I don' like the idea of documenting
possible behaviors, because it's non-portable, and really might change
in a future version)."

The description doesn't need to be precise, you can just say "depending on the platform, closing a file descriptor while selector.select() is polling may be ignored or raise an exception". Which can of exception is raised? It is possible to catch it and find the closed file descriptor?

----------

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

From report at bugs.python.org  Tue Dec  3 20:51:46 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 19:51:46 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386100305.96.0.51037800725.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I think you're looking for the discussion in issue 19017.

IIRC the conclusion is that not only do you not get the same error everywhere, but you get it at different points -- sometimes register() of a bad FD passes and then [Selector.]select() fails, other times register() of a bad FD fails; when the FD is initially good and then gets closed, sometimes select() may fail, sometimes select() will silently ignore the FD. Sometimes unregister() of a closed FD will return False, sometimes True.

Another consequence is that registering an FD, then closing it, then calling select(), then reopening it may keep reporting events for the FD or not.

I think these are all things to call out in a section on caveats or common bugs.

----------

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

From report at bugs.python.org  Tue Dec  3 22:48:50 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 03 Dec 2013 21:48:50 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386100305.96.0.51037800725.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2oRDroHKZk7-Bitna1ie6w2NtX3X4ypwhR=KAVCThtjA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Guido van Rossum added the comment:
>
> I think you're looking for the discussion in issue 19017.
>
> IIRC the conclusion is that not only do you not get the same error everywhere, but you get it at different points -- sometimes register() of a bad FD passes and then [Selector.]select() fails, other times register() of a bad FD fails; when the FD is initially good and then gets closed, sometimes select() may fail, sometimes select() will silently ignore the FD. Sometimes unregister() of a closed FD will return False, sometimes True.
>
> Another consequence is that registering an FD, then closing it, then calling select(), then reopening it may keep reporting events for the FD or not.

Exactly, it's a mess.

> I think these are all things to call out in a section on caveats or common bugs.

What I don't remember was the conclusion: do we want to keep the
current OS-specific behavior, or do we want to try to be tolerant with
misuse?
For example, one possibility would be to ignore errors when
unregistering a file descriptor from epoll: for example, the
selectmodule currently ignore EBADF when unregistering a FD:
"""
        case EPOLL_CTL_DEL:
        /* In kernel versions before 2.6.9, the EPOLL_CTL_DEL
         * operation required a non-NULL pointer in event, even
         * though this argument is ignored. */
        Py_BEGIN_ALLOW_THREADS
        result = epoll_ctl(epfd, op, fd, &ev);
        if (errno == EBADF) {
            /* fd already closed */
            result = 0;
            errno = 0;
        }
"""

IIRC libev and libevent both ignore those errors.

We have to settle on a solution before documenting it.

----------

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

From report at bugs.python.org  Tue Dec  3 23:24:36 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 22:24:36 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386109476.76.0.81750681113.issue19876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>>> import selectors, os
>>> r,w=os.pipe()
>>> s=selectors.SelectSelector()
>>> s.register(r, selectors.EVENT_READ)
SelectorKey(fileobj=3, fd=3, events=1, data=None)
>>> os.close(r)
>>> os.close(w)
>>> s.unregister(r)
SelectorKey(fileobj=3, fd=3, events=1, data=None)

SelectSelector.unregister(<closed fd>) doesn't raise any error, so it makes sense to ignore EBADF in EpollSelector.unregister(). What's the point of raising an error here?

If you want a portable behaviour, the file descriptor should be tested (ex: call os.fstat or os.dup). For the "normal" use case, I would not expect a syscall on unregister(), because unregister() may be called just before closing the file descriptor.

Maybe you can explain that in the "caveats" section? Suggestion: "unregister(fd) does not check if fd is closed or not (to get a portable behaviour), os.fstat() or os.dup() can be used to check if the fd is closed or not". Or "unregister(fd) ignores error if the file descriptor is closed".

----------

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

From report at bugs.python.org  Tue Dec  3 23:45:32 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 22:45:32 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386110732.13.0.93557427052.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Heh, I'd forgotten the behavior of unregister().  It seems that there are two layers to the behavior -- if this FD was never register()ed it will raise; if it was register()ed but has since been close()d it may raise.

For the higher-level APIs in asyncio I chose not to raise from the remove_{reader,writer}() methods -- they return True if something was removed, False if not.  This currently has to be implemented by explicitly asking the selector for the key first.  I.e.:

    def remove_reader(self, fd):
        """Remove a reader callback."""
        try:
            key = self._selector.get_key(fd)
        except KeyError:
            return False
        else:
            mask, (reader, writer) = key.events, key.data
            mask &= ~selectors.EVENT_READ
            if not mask:
                self._selector.unregister(fd)
            else:
                self._selector.modify(fd, mask, (None, writer))

            if reader is not None:
                reader.cancel()
                return True
            else:
                return False

----------

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

From report at bugs.python.org  Tue Dec  3 23:46:04 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 22:46:04 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386110764.16.0.324061357909.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

(What I meant to add was, I'd be happy if unregister() also just used a true/false return.)

----------

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

From report at bugs.python.org  Wed Dec  4 08:21:06 2013
From: report at bugs.python.org (Martin Panter)
Date: Wed, 04 Dec 2013 07:21:06 +0000
Subject: [docs] [issue19882] Closing a socket when makefile() is used
Message-ID: <1386141666.2.0.800726480915.issue19882@psf.upfronthosting.co.za>


New submission from Martin Panter:

I think the documentation is rather vague about closing the underlying OS socket. Can someone verify if the following is true (*asterisked* bits are my additions), and maybe update the documentation?

socket.close(): Close the socket *object*. *The underlying file descriptor is also closed, unless there are file objects from makefile() still open.*

socket.makefile(): Closing the file object won?t close the *file descriptor* unless *the original socket object and any other file objects have already been closed*.

----------
assignee: docs at python
components: Documentation
messages: 205200
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Closing a socket when makefile() is used
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Dec  4 09:35:53 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Dec 2013 08:35:53 +0000
Subject: [docs] [issue18840] Tutorial recommends pickle module without any
	warning of	insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386146153.56.0.795956790899.issue18840@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage: needs patch -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Wed Dec  4 13:40:38 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 04 Dec 2013 12:40:38 +0000
Subject: [docs] [issue18840] Tutorial recommends pickle module without any
	warning of	insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386160838.54.0.583691501221.issue18840@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Since this particular tutorial section was written long before the json module was part of the standard library, I think it makes sense to switch now we have the option.

pickle is definitely a useful tool, but now that JSON is available by default, it's now one to escalate to if JSON doesn't meet your needs, rather than the one to use by default.

Chris's patch looks generally good to me, although I think it could use a second paragraph in the pickle section. Perhaps something like:

"""JSON is much simpler to use safely than pickle, and offers broader interoperability with programs written in other languages. However, pickle has the advantage of supporting a much wider range of Python object types, including executable code, which means it can handle use cases that JSON can't (like sending code to another process for execution)"


This simpler/safer/less powerful API/technique vs more powerful/more dangerous API/technique trade-off is a fairly common one, so I think it's a good thing to have a concrete example of it in the tutorial rather than just dropping the reference to pickle entirely.

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

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

From report at bugs.python.org  Wed Dec  4 19:23:26 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 04 Dec 2013 18:23:26 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386181406.73.0.331177759645.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I just ran into a live case of the platform differences here.  Check out http://bugs.python.org/review/19509/ (issue 19509).  Christian uploaded a patch for asyncio, and when I tested it I got a double traceback and a hang.  This could have been avoided if the unregister() call for the closed FD had been silent instead of raising.

I think that the proper fix might have been not to close the socket, but nevertheless this failure confused everyone -- the author of the patch thought it had to do with the SSL version, I was initially confused by the first half of the traceback (which turned out to be expected, this was in an assertRaises() call), and I spent half an hour in pdb to track down the real cause.

----------

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

From report at bugs.python.org  Wed Dec  4 20:09:06 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 04 Dec 2013 19:09:06 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386184146.18.0.588608097024.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

The more I think about this the more I believe unregister() should catch the OSError (but not the KeyError).

Every unregister() implementation starts by calling super().unregister(key), which has a side effect (it removes the key from the _fd_to_key dict).

I believe that once this side effect has happened the unregister() call should return with success even if the kqueue syscall fails with OSError.

A further refinement could be to skip the kqueue syscall *if* the registered object is in fact an object with a fileno() method and not a bare FD, and the object is closed -- we should be able to tell that by calling its fileno() method, which should return -1 or None if it is closed.  (But this would be mostly an optimization -- and a safety guard in case the FD has been reused for a different object.)

I don't know how poll and epoll behave under these circumstances, but given that only the Kqueue-based asyncio test failed I think those don't raise when the FD has been closed.

If you are not amenable to this fix I will have to catch the OSError in Tulip's remove_reader(), e.g. like this:

            try:
                if not mask:
                    self._selector.unregister(fd)
                else:
                    self._selector.modify(fd, mask, (None, writer))
            except OSError:
                # unregister()/modify() may or may not raise this if
                # the FD is closed -- it depends on what type of
                # selector is used.
                pass

(and repeated in remove_writer()).

----------

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

From report at bugs.python.org  Wed Dec  4 20:14:09 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Wed, 04 Dec 2013 19:14:09 +0000
Subject: [docs] [issue18840] Tutorial recommends pickle module without any
	warning of	insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386184449.8.0.927985090954.issue18840@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

Sounds good to me.

----------

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

From report at bugs.python.org  Wed Dec  4 20:17:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 19:17:00 +0000
Subject: [docs] [issue18840] Tutorial recommends pickle module without any
	warning of	insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386184620.19.0.893102247761.issue18840@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Correction: you can't pickle executable code, you can pickle references to well-known objects (by name):

>>> def f(): pass
... 
>>> pickle.dumps(f)
b'\x80\x03c__main__\nf\nq\x00.'
>>> pickle.dumps(f.__code__)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_pickle.PicklingError: Can't pickle <class 'code'>: attribute lookup code on builtins failed

----------

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

From report at bugs.python.org  Wed Dec  4 20:46:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 19:46:25 +0000
Subject: [docs] [issue19882] Closing a socket when makefile() is used
In-Reply-To: <1386141666.2.0.800726480915.issue19882@psf.upfronthosting.co.za>
Message-ID: <1386186385.08.0.147564979002.issue19882@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Your observations are right, indeed. I'll make the doc changes.

----------
nosy: +pitrou
stage:  -> patch review
versions: +Python 2.7

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

From report at bugs.python.org  Wed Dec  4 21:12:02 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 04 Dec 2013 20:12:02 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386187922.12.0.643284009006.issue19871@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Oddly, with all of the strictness in JSON, the exponent-marker "e"
> can be upper- or lower-case

I'd guess that the aim is that common floating-point output formats from a variety of languages are valid JSON.  That would also explain why both '+' and '-' are allowed on the exponent, but only '-' on the significand, and why leading zeros are permitted on the exponent but not the significand.

----------

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

From report at bugs.python.org  Wed Dec  4 21:15:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Dec 2013 20:15:59 +0000
Subject: [docs] [issue19882] Closing a socket when makefile() is used
In-Reply-To: <1386141666.2.0.800726480915.issue19882@psf.upfronthosting.co.za>
Message-ID: <3dZWXZ1Z3gz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset e10bb7c1b8f8 by Antoine Pitrou in branch '3.3':
Issue #19882: tweak docs for socket.close()
http://hg.python.org/cpython/rev/e10bb7c1b8f8

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

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

From report at bugs.python.org  Wed Dec  4 21:16:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 20:16:24 +0000
Subject: [docs] [issue19882] Closing a socket when makefile() is used
In-Reply-To: <1386141666.2.0.800726480915.issue19882@psf.upfronthosting.co.za>
Message-ID: <1386188183.96.0.0966615545052.issue19882@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Fixed, thanks!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Dec  4 21:20:56 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Dec 2013 20:20:56 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386188456.3.0.981566735032.issue19871@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Dec  4 22:00:35 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 04 Dec 2013 21:00:35 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386190835.83.0.0342667169752.issue19871@psf.upfronthosting.co.za>


Tim Peters added the comment:

We should adhere to the json spec, but there's no harm (and some real good!) in the docs pointing out notable cases where json and Python syntax differ.

----------
nosy: +tim.peters

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

From report at bugs.python.org  Wed Dec  4 22:09:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 21:09:27 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386191367.67.0.560927268868.issue19871@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are too many cases where json and Python syntax differ. Final comma("[1, 2,]"), non-string keys ({1: 2}), tuples ("(1, 2)"), leading zeros ("0001"), hexadecimal integers ("0xaf"), escapes of astral characters('"\U0001d504"'), single quotes ("'spam'"), octal escape codes ("\015"), etc, etc...

----------

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

From report at bugs.python.org  Thu Dec  5 00:04:12 2013
From: report at bugs.python.org (Antony Lee)
Date: Wed, 04 Dec 2013 23:04:12 +0000
Subject: [docs] [issue19890] Typo in multiprocessing docs
Message-ID: <1386198252.12.0.881873603907.issue19890@psf.upfronthosting.co.za>


New submission from Antony Lee:

The docs for multiprocessing refer to BaseProxy._callMethod() while it should be _callmethod.

----------
assignee: docs at python
components: Documentation
messages: 205261
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Typo in multiprocessing docs
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Dec  5 10:26:49 2013
From: report at bugs.python.org (Richard Milne)
Date: Thu, 05 Dec 2013 09:26:49 +0000
Subject: [docs] [issue19894] zipfile ignores deflate level settings in
	zipinfo object
Message-ID: <1386235609.47.0.431866049959.issue19894@psf.upfronthosting.co.za>


New submission from Richard Milne:

Reading the pkzip APPNOTE and the documentation for the zipfile module, I was under the impression that I could set the DEFLATE compression level, on a per-file basis, for each file added to an archive, by setting the appropriate bits in zipinfo.flag_bits.

You can't. Hence the attached patch, which updates the docs, tests and module source to enables this ability and makes the user aware of it.

----------
assignee: docs at python
components: Documentation, Library (Lib), Tests
files: zipfileinfo.diff
keywords: patch
messages: 205284
nosy: docs at python, rmilne
priority: normal
severity: normal
status: open
title: zipfile ignores deflate level settings in zipinfo object
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file32984/zipfileinfo.diff

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

From report at bugs.python.org  Thu Dec  5 14:08:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Dec 2013 13:08:31 +0000
Subject: [docs] [issue19894] zipfile ignores deflate level settings in
	zipinfo object
In-Reply-To: <1386235609.47.0.431866049959.issue19894@psf.upfronthosting.co.za>
Message-ID: <1386248911.9.0.0846227383418.issue19894@psf.upfronthosting.co.za>


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


----------
nosy: +alanmcintyre, serhiy.storchaka
stage:  -> patch review

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

From report at bugs.python.org  Thu Dec  5 14:20:04 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 Dec 2013 13:20:04 +0000
Subject: [docs] [issue19897] Use python as executable instead of python3 in
	Python 2	docs
Message-ID: <1386249604.05.0.79592936078.issue19897@psf.upfronthosting.co.za>


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


----------
assignee: docs at python
components: Documentation
files: fix-example-site.diff
keywords: patch
nosy: berker.peksag, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Use python as executable instead of python3 in Python 2 docs
versions: Python 2.7
Added file: http://bugs.python.org/file32988/fix-example-site.diff

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

From report at bugs.python.org  Thu Dec  5 18:46:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 17:46:01 +0000
Subject: [docs] [issue18840] Tutorial recommends pickle module without any
	warning of	insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386265560.51.0.456385932977.issue18840@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a modified patch. The changes are:
- pickle is deemphasized a lot more (it's moved into a "seealso")
- I replaced the terms "encoding" and "decoding" with "serializing" and "deserializing" (the former may be confusing for people who are already struggling to understand the bytes / unicode gap)
- I added a glossary entry for "text file" and pointed to it

----------
Added file: http://bugs.python.org/file32994/tutjson.patch

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

From report at bugs.python.org  Thu Dec  5 19:06:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 18:06:48 +0000
Subject: [docs] [issue19900] improve pickle intro
Message-ID: <1386266808.09.0.595733431093.issue19900@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This patch improved the generalities at the top of the pickle module docs.

----------
assignee: docs at python
components: Documentation
files: pickintro.patch
keywords: patch
messages: 205316
nosy: alexandre.vassalotti, docs at python, ncoghlan, pitrou, tim.peters
priority: normal
severity: normal
stage: patch review
status: open
title: improve pickle intro
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32995/pickintro.patch

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

From report at bugs.python.org  Thu Dec  5 23:17:34 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Dec 2013 22:17:34 +0000
Subject: [docs] [issue18840] Tutorial recommends pickle module without any
	warning of	insecurity
In-Reply-To: <1386265560.51.0.456385932977.issue18840@psf.upfronthosting.co.za>
Message-ID: <CADiSq7es=C+5VdkZNCpMcptAy7dmi1YSMmz04=vj_68UpYU-rw@mail.gmail.com>


Nick Coghlan added the comment:

Antoine's latest draft looks good to me.

----------

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

From report at bugs.python.org  Thu Dec  5 23:41:55 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 05 Dec 2013 22:41:55 +0000
Subject: [docs] [issue18840] Tutorial recommends pickle module without any
	warning of	insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386283315.03.0.57239213278.issue18840@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I like Antoine's tutjson.patch.  commit it.  Thanks for noticing this Donald!

----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Thu Dec  5 23:44:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 22:44:52 +0000
Subject: [docs] [issue18840] Tutorial recommends pickle module without any
	warning of	insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386283492.96.0.192816812677.issue18840@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

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

From report at bugs.python.org  Thu Dec  5 23:48:18 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Dec 2013 22:48:18 +0000
Subject: [docs] [issue18840] Tutorial recommends pickle module without any
	warning of	insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <3dbBss6vhdz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 90cf299dcf9b by Antoine Pitrou in branch '3.3':
Issue #18840: Introduce the json module in the tutorial, and deemphasize the pickle module.
http://hg.python.org/cpython/rev/90cf299dcf9b

New changeset 1009b77f59fd by Antoine Pitrou in branch 'default':
Issue #18840: Introduce the json module in the tutorial, and deemphasize the pickle module.
http://hg.python.org/cpython/rev/1009b77f59fd

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

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

From report at bugs.python.org  Thu Dec  5 23:52:08 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Dec 2013 22:52:08 +0000
Subject: [docs] [issue18840] Tutorial recommends pickle module without any
	warning of	insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <3dbByH1kFqz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 481b30bfe496 by Antoine Pitrou in branch '2.7':
Issue #18840: Introduce the json module in the tutorial, and deemphasize the pickle module.
http://hg.python.org/cpython/rev/481b30bfe496

----------

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

From report at bugs.python.org  Thu Dec  5 23:52:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 22:52:45 +0000
Subject: [docs] [issue18840] Tutorial recommends pickle module without any
	warning of	insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386283965.45.0.0147190506319.issue18840@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, I've committed it. Thanks!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7

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

From report at bugs.python.org  Fri Dec  6 00:14:54 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 05 Dec 2013 23:14:54 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386285294.82.0.827316738734.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Here's a tentative change to selectors.py that ignores the OSError in various unregister() methods (but not in register()).

----------
keywords: +patch
Added file: http://bugs.python.org/file32999/unregister.diff

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

From report at bugs.python.org  Fri Dec  6 00:16:32 2013
From: report at bugs.python.org (follower)
Date: Thu, 05 Dec 2013 23:16:32 +0000
Subject: [docs] [issue19902] logging docs don't document integer constants
Message-ID: <1386285391.99.0.345532984259.issue19902@psf.upfronthosting.co.za>


New submission from follower:

The logging module documentation <http://docs.python.org/3.4/library/logging.html> makes reference to the levels DEBUG, INFO etc (e.g. in <http://docs.python.org/3.4/library/logging.html#logging.Logger.setLevel>) but AFAICT these constants are not documented in the module itself.

e.g I would expect a section like this

Level Constants
logging.DEBUG 10
logging.INFO  20
etc etc

(Although the actual values may not be listed depending on what your policy is for documenting "magic numbers".)

----------
assignee: docs at python
components: Documentation
messages: 205334
nosy: docs at python, follower
priority: normal
severity: normal
status: open
title: logging docs don't document integer constants
type: enhancement
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri Dec  6 01:19:02 2013
From: report at bugs.python.org (Alexander Boyd)
Date: Fri, 06 Dec 2013 00:19:02 +0000
Subject: [docs] [issue12955] urllib.request example should use "with ... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <1386289142.45.0.57265602049.issue12955@psf.upfronthosting.co.za>


Changes by Alexander Boyd <alex at opengroove.org>:


----------
nosy: +javawizard

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

From report at bugs.python.org  Fri Dec  6 04:54:40 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 06 Dec 2013 03:54:40 +0000
Subject: [docs] [issue19900] improve pickle intro
In-Reply-To: <1386266808.09.0.595733431093.issue19900@psf.upfronthosting.co.za>
Message-ID: <1386302080.77.0.450074090279.issue19900@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Looks good to me!

----------

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

From report at bugs.python.org  Fri Dec  6 05:07:48 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 06 Dec 2013 04:07:48 +0000
Subject: [docs] [issue19900] improve pickle intro
In-Reply-To: <1386302080.77.0.450074090279.issue19900@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dwdM8rysJObA3E=Da_VKOzg978uZFg4AsvVBi4_0oUWA@mail.gmail.com>


Nick Coghlan added the comment:

Looks good to me, although I'm not sure the specific note about the C
accelerator is needed.

----------

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

From report at bugs.python.org  Fri Dec  6 11:46:04 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 06 Dec 2013 10:46:04 +0000
Subject: [docs] [issue19906] Typo in urllib documentation
Message-ID: <1386326764.33.0.520291465102.issue19906@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

In the first note from urllib.rst, there is a reference to urllib being replaced by urllib2 in Python 3, which is False.

----------
assignee: docs at python
components: Documentation
files: urllib2.patch
keywords: patch
messages: 205359
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Typo in urllib documentation
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file33002/urllib2.patch

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

From report at bugs.python.org  Fri Dec  6 12:01:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Dec 2013 11:01:28 +0000
Subject: [docs] [issue19900] improve pickle intro
In-Reply-To: <CADiSq7dwdM8rysJObA3E=Da_VKOzg978uZFg4AsvVBi4_0oUWA@mail.gmail.com>
Message-ID: <1386327686.2298.0.camel@fsol>


Antoine Pitrou added the comment:

> Looks good to me, although I'm not sure the specific note about the C
> accelerator is needed.

Neither am I. I moved it to the end to deemphasize it, but we can as
well remove it.

----------

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

From report at bugs.python.org  Fri Dec  6 17:01:24 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 16:01:24 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386345684.06.0.765236466183.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Ping? Charle-Fran?ois, what do you think of my patch to ignore OSError in unregister()?

----------
assignee: docs at python -> neologix

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

From report at bugs.python.org  Fri Dec  6 17:12:46 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 16:12:46 +0000
Subject: [docs] [issue19910] Document that compile() source may be bytes
Message-ID: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

compile() takes a string, bytes or AST as the "source" argument.  The bytes option are not documented except in the error message you get when you pass something else.  The AST option is in the library docs but not in the function docstring.

----------
assignee: docs at python
components: Documentation
messages: 205383
nosy: docs at python, gvanrossum
priority: normal
severity: normal
status: open
title: Document that compile() source may be bytes
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec  6 17:14:31 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 16:14:31 +0000
Subject: [docs] [issue19910] Document that compile() source may be bytes
In-Reply-To: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>
Message-ID: <1386346471.95.0.205928501742.issue19910@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
keywords: +easy
priority: normal -> low
stage:  -> needs patch

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

From report at bugs.python.org  Fri Dec  6 17:46:46 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 06 Dec 2013 16:46:46 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386345684.06.0.765236466183.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM02pjCueto9SsFxU5LjuyFTGmAAF5tYDDTLwUOoUQiPNw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Sorry for the delay, I didn't have any free time this week.
I'll review the patch shortly, but the idea sounds fine (I just need
to check if we can't be a little more specific for errnos upon
unregister).

----------

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

From report at bugs.python.org  Fri Dec  6 18:29:17 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Dec 2013 17:29:17 +0000
Subject: [docs] [issue19910] Document that compile() source may be bytes
In-Reply-To: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>
Message-ID: <1386350957.63.0.082494940092.issue19910@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Dec  6 18:33:01 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Dec 2013 17:33:01 +0000
Subject: [docs] [issue19906] Typo in urllib documentation
In-Reply-To: <1386326764.33.0.520291465102.issue19906@psf.upfronthosting.co.za>
Message-ID: <1386351181.97.0.386534218529.issue19906@psf.upfronthosting.co.za>


?ric Araujo added the comment:

LGTM.

----------
nosy: +eric.araujo, ezio.melotti
stage:  -> commit review

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

From report at bugs.python.org  Fri Dec  6 22:40:32 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 21:40:32 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386366032.25.0.36813667749.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Here's a new patch.  Note that it includes a commented-out test that demonstrates the failure if the socket object itself is closed (rather than just its FD).

----------
Added file: http://bugs.python.org/file33013/unregister2.diff

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

From report at bugs.python.org  Fri Dec  6 23:00:53 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 22:00:53 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386367253.07.0.59743525311.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Here's a variant that documents the ValueError issue and omits the commented-out test.

----------
Added file: http://bugs.python.org/file33014/unregister3.diff

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

From report at bugs.python.org  Fri Dec  6 23:15:16 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 22:15:16 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386368116.71.0.314149961478.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Here's an attempt at fixing the ValueError.

I don't like the exhaustive search much, but the alternative is to maintain an inverse dict.  What do you think?

----------
Added file: http://bugs.python.org/file33015/unregister4.diff

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

From report at bugs.python.org  Fri Dec  6 23:59:10 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 06 Dec 2013 22:59:10 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386368116.71.0.314149961478.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0KE-7Yu0_VEm+Bw8DcD_FoxoM_ghKLLig42K5hc-ojSQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Guido van Rossum added the comment:
>
> Here's an attempt at fixing the ValueError.
>
> I don't like the exhaustive search much, but the alternative is to maintain an inverse dict.  What do you think?

I was going to suggest such an exhaustive search.
I think it's the cleanest/simplest solution, and the performance
overhead is IMO completely unimportant since it's not supposed to
happen often, and if the key isn't found we're going to raise an
exception anyway.

So if we want to handle this case (and I think we should to be
consistent), that's the best way to go.

But I think that OSError should still be caught in
EpollSelector.unregister(): since if the FD is closed before,
epoll.unregister() will raise ENOENT/EBADF since the FD will have
automatically been removed (exactly as for kqueue according to the man
page).

----------

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

From report at bugs.python.org  Sat Dec  7 00:18:50 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 23:18:50 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386371930.11.0.0896296625338.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, I'll make a new patch (maybe Monday).  I want to be a little more careful with the exhaustive search, I think it should not be attempted if we see KeyError or AttributeError (those should not be dynamic).

I tested for the epoll error on Ubuntu and didn't get OSError, but I'm happy to keep it in if the man pays says so.  (How sure are you about poll() not doing this?)

----------

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

From report at bugs.python.org  Sat Dec  7 00:57:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Dec 2013 23:57:51 +0000
Subject: [docs] [issue19900] improve pickle intro
In-Reply-To: <1386266808.09.0.595733431093.issue19900@psf.upfronthosting.co.za>
Message-ID: <3dbrMg1RNWz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 609325d187bf by Antoine Pitrou in branch '3.3':
Issue #19900: improve generalities at the start of the pickle module doc
http://hg.python.org/cpython/rev/609325d187bf

New changeset 595b8f82569c by Antoine Pitrou in branch 'default':
Issue #19900: improve generalities at the start of the pickle module doc
http://hg.python.org/cpython/rev/595b8f82569c

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

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

From report at bugs.python.org  Sat Dec  7 01:06:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 00:06:28 +0000
Subject: [docs] [issue19900] improve pickle intro
In-Reply-To: <1386266808.09.0.595733431093.issue19900@psf.upfronthosting.co.za>
Message-ID: <1386374788.51.0.229657900858.issue19900@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Dec  7 01:30:49 2013
From: report at bugs.python.org (Fotis Koutoulakis)
Date: Sat, 07 Dec 2013 00:30:49 +0000
Subject: [docs] [issue19910] Document that compile() source may be bytes
In-Reply-To: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>
Message-ID: <1386376249.88.0.404316576547.issue19910@psf.upfronthosting.co.za>


Fotis Koutoulakis added the comment:

There we go. I have changed the references to compile(), both in the docstring, and the documentation so that it states clearly that a bytes object is also acceptable as the "source" argument.

I also fixed the docstring to mention explicitly that it can also accept an AST as the "source argument".

Since this is my very first contribution to Python, I welcome all feedback. Thanks for your time.

----------
keywords: +patch
nosy: +Fotis.Koutoulakis
Added file: http://bugs.python.org/file33018/issue19910_python.patch

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

From report at bugs.python.org  Sat Dec  7 01:36:28 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 Dec 2013 00:36:28 +0000
Subject: [docs] [issue19910] Document that compile() source may be bytes
In-Reply-To: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>
Message-ID: <1386376588.93.0.220477637933.issue19910@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks!  Patch looks good to me.

----------
keywords: +needs review
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Dec  7 01:59:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 00:59:58 +0000
Subject: [docs] [issue19910] Document that compile() source may be bytes
In-Reply-To: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>
Message-ID: <1386377998.93.0.245833545946.issue19910@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Sat Dec  7 02:15:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Dec 2013 01:15:05 +0000
Subject: [docs] [issue19910] Document that compile() source may be bytes
In-Reply-To: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>
Message-ID: <3dbt4c2HhBz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 500cc1acc42f by Benjamin Peterson in branch '3.3':
document that compile() can take bytes (closes #19910)
http://hg.python.org/cpython/rev/500cc1acc42f

New changeset 44dacafdd48a by Benjamin Peterson in branch 'default':
merge 3.3 (#19910)
http://hg.python.org/cpython/rev/44dacafdd48a

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Dec  7 02:51:30 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 01:51:30 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386381090.34.0.467347621107.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

So I think this is why epoll doesn't raise OSError:

http://hg.python.org/cpython/file/44dacafdd48a/Modules/selectmodule.c#l1335

The Python wrapper explicitly checks for EBADF and turns this into a non-error result.

----------

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

From report at bugs.python.org  Sat Dec  7 02:58:56 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 01:58:56 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386381536.61.0.888590575063.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Well, I take it back. If you close the FD and then reuse it, you get ENOENT, which is not caught.  So we still need the try/except OSError.

I am going to experiment with a PollSelector as well.

----------

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

From report at bugs.python.org  Sat Dec  7 03:00:32 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 02:00:32 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386381632.44.0.788357783542.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

PollSelector doesn't seem to have this behavior.

----------

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

From report at bugs.python.org  Sat Dec  7 04:37:32 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 03:37:32 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386387452.77.0.21125493009.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

New patch. Please review.

The error handling is a bit complicated but I like to be careful in which errors I catch.

----------
Added file: http://bugs.python.org/file33020/unregister5.diff

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

From report at bugs.python.org  Sat Dec  7 10:16:43 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 07 Dec 2013 09:16:43 +0000
Subject: [docs] [issue6673] Uncaught comprehension SyntaxError eats up all
	memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1386407803.03.0.00379901152643.issue6673@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
nosy:  -alexandre.vassalotti

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

From report at bugs.python.org  Sat Dec  7 10:32:30 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 07 Dec 2013 09:32:30 +0000
Subject: [docs] [issue12290] __setstate__ is called for false values
In-Reply-To: <1307586060.34.0.652262251036.issue12290@psf.upfronthosting.co.za>
Message-ID: <1386408750.44.0.870857954348.issue12290@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
stage:  -> patch review
versions: +Python 3.4 -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Dec  7 10:33:41 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 07 Dec 2013 09:33:41 +0000
Subject: [docs] [issue12290] __setstate__ is called for false values
In-Reply-To: <1307586060.34.0.652262251036.issue12290@psf.upfronthosting.co.za>
Message-ID: <1386408821.0.0.0922668428188.issue12290@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Dec  7 13:47:49 2013
From: report at bugs.python.org (Jon Clements)
Date: Sat, 07 Dec 2013 12:47:49 +0000
Subject: [docs] [issue18925] select.poll.modify is not documented
In-Reply-To: <1378328037.99.0.424927131422.issue18925@psf.upfronthosting.co.za>
Message-ID: <1386420469.75.0.682961680965.issue18925@psf.upfronthosting.co.za>


Jon Clements added the comment:

Was looking up epoll.modify and noticed in the docs it's listed as "
Modify a register file descriptor." - I believe that should be "Modify a registered file descriptor"...

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

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

From report at bugs.python.org  Sat Dec  7 17:49:40 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 16:49:40 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386434979.98.0.170615355055.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Sorry, here's another version. It keeps the original _fileobj_to_fd function and wraps it with a method that does the exhaustive search.

----------
Added file: http://bugs.python.org/file33025/unregister6.diff

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

From report at bugs.python.org  Sat Dec  7 20:01:23 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 19:01:23 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386442883.39.0.830678903315.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I think I got the closing sorted out now, and through reordering the dup2() calls are actually needed.

----------
Added file: http://bugs.python.org/file33028/unregister7.diff

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

From report at bugs.python.org  Sat Dec  7 21:22:29 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 20:22:29 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386447749.59.0.56038356385.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, here's another try. I ran what you suggested for all three tests I added and they are all clean.  I realized that every single call to socketpair() is followed by two addCleanup calls, so I added a make_socketpair() helper method that does this.

----------
Added file: http://bugs.python.org/file33029/unregister8.diff

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

From report at bugs.python.org  Sat Dec  7 23:53:07 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 07 Dec 2013 22:53:07 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386447749.59.0.56038356385.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0Abn8bmzgy7hckSq3ZZUTP38i7Q-ibKZPRSdHfAaeeAQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

LGTM!

----------

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

From report at bugs.python.org  Sun Dec  8 00:57:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Dec 2013 23:57:15 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <3dcSJV1CwXz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 39e7995f9ad1 by Guido van Rossum in branch 'default':
Silently ignore unregistering closed files. Fixes issue 19876. With docs and slight test refactor.
http://hg.python.org/cpython/rev/39e7995f9ad1

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

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

From report at bugs.python.org  Sun Dec  8 00:59:32 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 23:59:32 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386460772.27.0.201912377383.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Is this worthy of a Misc/NEWS entry?

----------

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

From report at bugs.python.org  Sun Dec  8 01:03:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 00:03:46 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <3dcSS140wsz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset f334dd2471e7 by Guido van Rossum in branch 'default':
News item for issue 19876.
http://hg.python.org/cpython/rev/f334dd2471e7

----------

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

From report at bugs.python.org  Sun Dec  8 01:04:55 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 08 Dec 2013 00:04:55 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386461095.2.0.266037399641.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Done.

----------
assignee: neologix -> gvanrossum
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Sun Dec  8 09:53:33 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Dec 2013 08:53:33 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386492812.9.0.267959687164.issue19876@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

The test is failing on Windows buildbot:
http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%203.x/builds/1851/steps/test/logs/stdio
"""
======================================================================
ERROR: test_unregister_after_fd_close_and_reuse (test.test_selectors.DefaultSelectorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_selectors.py", line 122, in test_unregister_after_fd_close_and_reuse
    os.dup2(rd2.fileno(), r)
OSError: [Errno 9] Bad file descriptor

======================================================================
ERROR: test_unregister_after_fd_close_and_reuse (test.test_selectors.SelectSelectorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_selectors.py", line 122, in test_unregister_after_fd_close_and_reuse
    os.dup2(rd2.fileno(), r)
OSError: [Errno 9] Bad file descriptor
"""

Apparently, dup2() doesn't work on Windows because on Windows, sockets aren't file descriptors, but a different beast...

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

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

From report at bugs.python.org  Sun Dec  8 12:01:45 2013
From: report at bugs.python.org (alexd2)
Date: Sun, 08 Dec 2013 11:01:45 +0000
Subject: [docs] [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1386500505.44.0.273518590993.issue17259@psf.upfronthosting.co.za>


alexd2 added the comment:

I encountered the same inconsistent behavior. That is, I don't get the same rounding from the two following commands:

print "%.f %.f" %(0.5, 1.5)               # Gives --> 0 2
print "%.f %.f" %(round(0.5), round(1.5)) # Gives --> 1 2

I also get:
print round(0.5), round(1.5) # Gives --> 1.0 2.0

>From what I read in the thread it seems to be more like a bug rather than something to just be documented, right?

----------
nosy: +alexd2

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

From report at bugs.python.org  Sun Dec  8 12:22:14 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 11:22:14 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386501734.2.0.686356422804.issue19876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I don't like generic "except OSError: pass". Here is a first patch for epoll() to use "except FileNotFoundError: pass" instead. Kqueue selector should also be patched.

I tested to close epoll FD (os.close(epoll.fileno())): on Linux 3.11, epoll.unregister(fd) and epoll.close() don't raise an error. Strange. (The C code looks correct).

(About the commit: I don't like "_fileobj_lookup" method name, we loose the information (compared to "_fileobj_to_fd" name) that the method returns a file dscriptor. I would prefer "_get_fd" or "_get_fileobj_fd".)

----------
resolution: fixed -> 
Added file: http://bugs.python.org/file33045/epoll_except.patch

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

From report at bugs.python.org  Sun Dec  8 13:12:00 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Dec 2013 12:12:00 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386501734.2.0.686356422804.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2VFiYXp-tS0D5VinVU5=ai96fkePSwbqc7fU02e7Z2Ug@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> STINNER Victor added the comment:
>
> I don't like generic "except OSError: pass". Here is a first patch for epoll() to use "except FileNotFoundError: pass" instead. Kqueue selector should also be patched.

Except that it can fail with ENOENT, but also EBADF, and EPERM if the
FD has been reused by a FD which doesn't support epoll.
So if we want to go this way, we should at least catach ENOENT, EBADF
and EPERM. Same for kqueue: we should at least catch ENOENT and EBADF.

> I tested to close epoll FD (os.close(epoll.fileno())): on Linux 3.11, epoll.unregister(fd) and epoll.close() don't raise an error. Strange. (The C code looks correct).

unregister() ignores EBADF.

> (About the commit: I don't like "_fileobj_lookup" method name, we loose the information (compared to "_fileobj_to_fd" name) that the method returns a file dscriptor. I would prefer "_get_fd" or "_get_fileobj_fd".)

Well, Guido likes it, I like it, and this is really nit-picking
(especially since it's a private method).

----------

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

From report at bugs.python.org  Sun Dec  8 14:36:21 2013
From: report at bugs.python.org (alexd2)
Date: Sun, 08 Dec 2013 13:36:21 +0000
Subject: [docs] [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1386509780.97.0.579389784691.issue17259@psf.upfronthosting.co.za>


alexd2 added the comment:

Note:
I have python2.7.3 in Ubuntu 12.04.3 installed in a VirtualBox VM on a Windows 7 32-bit and an Intel(R) Core(TM)2 Duo CPU U9300 @ 1.20GHz (2 CPUs), ~1.2GHz processor

----------

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

From report at bugs.python.org  Sun Dec  8 19:50:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 18:50:27 +0000
Subject: [docs] [issue18430] gzip, bz2,
	lzma: peek advances file position of existing file object
In-Reply-To: <1373571241.88.0.314815867736.issue18430@psf.upfronthosting.co.za>
Message-ID: <3dcxS21ctWz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 5ca6e8af0aab by Nadeem Vawda in branch '3.3':
#18430: Document that peek() may change the position of the underlying file for
http://hg.python.org/cpython/rev/5ca6e8af0aab

New changeset 0f587fe304be by Nadeem Vawda in branch 'default':
Closes #18430: Document that peek() may change the position of the underlying
http://hg.python.org/cpython/rev/0f587fe304be

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Dec  8 22:06:48 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 08 Dec 2013 21:06:48 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386536808.1.0.522639690707.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I don't think we should be more selective about the errno values, the try block is narrow enough (just one syscall) and we really don't know what the kernel will do on different platforms.  And what would we do about it anyway?

I will look into the Windows problem, but I suspect the best we can do there is skip the test.

----------

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

From report at bugs.python.org  Sun Dec  8 22:20:00 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Dec 2013 21:20:00 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386536808.1.0.522639690707.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3BiM4YUXpmAYm6KnUZjaDcz4Z5OSAQU4z58S7dCL7ObQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> I will look into the Windows problem, but I suspect the best we can do there is skip the test.

I already took care of that:
http://hg.python.org/cpython/rev/01676a4c16ff

----------

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

From report at bugs.python.org  Sun Dec  8 22:21:43 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 08 Dec 2013 21:21:43 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386537703.31.0.272825907102.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Then here's a hopeful fix for the Windows situation that relies on the socketpair() operation reusing FDs from the lowest value. I'm adding asserts to check that this is actually the case. (These are actual assert statements to indicate that they are verifying an assumption internal to the test, not verifying the functionality under test.)

I'll test it when I next get near a Windows box (Monday in the office) -- or someone else with Windows access can let me know.

----------
Added file: http://bugs.python.org/file33048/nodup2.diff

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

From report at bugs.python.org  Mon Dec  9 01:57:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Dec 2013 00:57:34 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <3dd5bb6FZPz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset c4c1c4bc8086 by Victor Stinner in branch 'default':
Issue #19876: Run also test_selectors.test_unregister_after_fd_close_and_reuse() on Windows
http://hg.python.org/cpython/rev/c4c1c4bc8086

----------

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

From report at bugs.python.org  Mon Dec  9 01:59:59 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 00:59:59 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386550799.6.0.0914291790593.issue19876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oops, I reverted my changeset c4c1c4bc8086, I didn't read why the test was skipped on Windows. Sorry.

----------

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

From report at bugs.python.org  Mon Dec  9 02:01:06 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 01:01:06 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386550866.65.0.314450489276.issue19876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Except that it can fail with ENOENT, but also EBADF, and EPERM if the
FD has been reused by a FD which doesn't support epoll."

Oh, I didn't know that. I ran the unit test, and I expected the two unit test to cover any error case. So ignore my epoll_except.patch, the current "except OSError: pass" is correct.

----------

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

From report at bugs.python.org  Mon Dec  9 02:14:22 2013
From: report at bugs.python.org (Fotis Koutoulakis)
Date: Mon, 09 Dec 2013 01:14:22 +0000
Subject: [docs] [issue18576] Rename and document test.script_helper
	as	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386551661.09.0.324883144126.issue18576@psf.upfronthosting.co.za>


Fotis Koutoulakis added the comment:

I have finished the changes needed to move script_helper from Lib/test to Lib/test/support, and I have also documented it. Tests run gracefully (but be sure to check out if it works as intended on your machines too)

Two notes though:

1. I have only made the changes on the default branch. Will do 3.3 tomorrow.

2. When it came to the documentation, I had to break the 80 characters limit, as going by it was resulting in weird rendering or wrong information depicted from sphinx (for example, when showing that script_helper functions belonged to test.support instead of the correct location, test.support.script_helper).

Last but not least, this is one of my first contributions to Python, so I would appreciate your input.

----------
keywords: +patch
nosy: +Fotis.Koutoulakis
Added file: http://bugs.python.org/file33049/script_helper-default.patch

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

From report at bugs.python.org  Mon Dec  9 02:57:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Dec 2013 01:57:02 +0000
Subject: [docs] [issue18576] Rename and document test.script_helper
	as	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386554222.87.0.406265968465.issue18576@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I wouldn't worry about 3.3 at this point - the 3.3 test suite isn't going to see major changes for its final release, so the risk of merge conflicts is low.

----------
versions:  -Python 3.3

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

From report at bugs.python.org  Mon Dec  9 03:02:04 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Dec 2013 02:02:04 +0000
Subject: [docs] [issue18576] Rename and document test.script_helper
	as	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386554524.16.0.538319378232.issue18576@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee: docs at python -> ncoghlan

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

From report at bugs.python.org  Mon Dec  9 05:24:20 2013
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 09 Dec 2013 04:24:20 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
Message-ID: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo:

>From the docs for built-in function "round":
   "If ndigits is omitted, it defaults to zero"
   (http://docs.python.org/3/library/functions.html#round)

But, the only way to get an integer from `round` is by not having the second argument (ndigits):

    >>> round(3.5)
    4
    >>> round(3.5, 1)
    3.5
    >>> round(3.5, 0)
    4.0
    >>> round(3.5, -1)
    0.0
    >>> round(3.5, None)
    Traceback (most recent call last):
      File "<pyshell#6>", line 1, in <module>
        round(3.5, None)
    TypeError: 'NoneType' object cannot be interpreted as an integer


Either the docs are wrong or the behavior is wrong. I think it's easier to fix the former...

But also there should be a way to make round return an integer (e.g. passing `None` as 2nd argument)

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 205647
nosy: JBernardo, docs at python
priority: normal
severity: normal
status: open
title: Round default argument for "ndigits"
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec  9 05:54:38 2013
From: report at bugs.python.org (Matthew Gilson)
Date: Mon, 09 Dec 2013 04:54:38 +0000
Subject: [docs] [issue19934] collections.Counter.most_common does not
	document `None`	as acceptable input.
Message-ID: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za>


New submission from Matthew Gilson:

Reading the source for collections.Counter.most_common, the docstring mentions that `n` can be `None` or omitted, but the online documentation does not mention that `n` can be `None`.

----------
assignee: docs at python
components: Documentation
messages: 205648
nosy: docs at python, mgilson
priority: normal
severity: normal
status: open
title: collections.Counter.most_common does not document `None` as acceptable input.

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

From report at bugs.python.org  Mon Dec  9 05:59:56 2013
From: report at bugs.python.org (Matthew Gilson)
Date: Mon, 09 Dec 2013 04:59:56 +0000
Subject: [docs] [issue19934] collections.Counter.most_common does not
	document `None`	as acceptable input.
In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za>
Message-ID: <1386565196.04.0.355334813737.issue19934@psf.upfronthosting.co.za>


Matthew Gilson added the comment:

This is a very simple patch which addresses the issue.  I am still curious whether the reported function signature should be changed from:

    .. method:: most_common([n])

to:

    .. method:: most_common(n=None)

.  Any thoughts?

Also, while I was in there, I changed a few *None* to ``None`` for consistency with the rest of the documentation.

----------
keywords: +patch
Added file: http://bugs.python.org/file33050/mywork.patch

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

From report at bugs.python.org  Mon Dec  9 07:52:30 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 06:52:30 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386571950.57.0.635364876825.issue19933@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the preliminary patch.

After patch:

round(1.23, 0) => 1 not 1.0

round(4.67, 0) => 5 not 5.0

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file33051/fix_round_with_zero_ndigits.patch

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

From report at bugs.python.org  Mon Dec  9 07:53:13 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 06:53:13 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386571993.3.0.763786915093.issue19933@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


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

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

From report at bugs.python.org  Mon Dec  9 08:02:16 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 07:02:16 +0000
Subject: [docs] [issue19934] collections.Counter.most_common does not
	document `None`	as acceptable input.
In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za>
Message-ID: <1386572536.58.0.0381601087268.issue19934@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


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

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

From report at bugs.python.org  Mon Dec  9 09:30:47 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2013 08:30:47 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386577847.69.0.681233550112.issue19933@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> After patch:
> round(1.23, 0) => 1 not 1.0
> round(4.67, 0) => 5 not 5.0

Please no!  Two-argument round should continue to return a float in all cases.

The docs should be fixed.

----------

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

From report at bugs.python.org  Mon Dec  9 09:32:07 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2013 08:32:07 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386577927.34.0.562343917751.issue19933@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> But also there should be a way to make round return an integer

I don't understand.  There's already a way to make round return an integer: don't pass a second argument.

----------

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

From report at bugs.python.org  Mon Dec  9 09:56:39 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 08:56:39 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386579399.38.0.211814636939.issue19933@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Okay, here is the patch to fix the doc.

----------
Added file: http://bugs.python.org/file33052/fix_doc_round_ndigits.patch

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

From report at bugs.python.org  Mon Dec  9 09:57:09 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 08:57:09 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386579429.7.0.682529013351.issue19933@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file33052/fix_doc_round_ndigits.patch

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

From report at bugs.python.org  Mon Dec  9 09:57:23 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 08:57:23 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386579443.02.0.756161054491.issue19933@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file33053/fix_doc_round_ndigits.patch

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

From report at bugs.python.org  Mon Dec  9 09:57:58 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 08:57:58 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386579478.93.0.0506852276459.issue19933@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file33053/fix_doc_round_ndigits.patch

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

From report at bugs.python.org  Mon Dec  9 09:58:06 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 08:58:06 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386579486.35.0.353574028033.issue19933@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file33054/fix_doc_round_ndigits.patch

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

From report at bugs.python.org  Mon Dec  9 10:46:27 2013
From: report at bugs.python.org (Fotis Koutoulakis)
Date: Mon, 09 Dec 2013 09:46:27 +0000
Subject: [docs] [issue18576] Rename and document test.script_helper
	as	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386582387.27.0.987544731097.issue18576@psf.upfronthosting.co.za>


Fotis Koutoulakis added the comment:

Hello again.

Is everything ok with the patch? Is there something not working as expected? Perhaps an omission or something? Do I need to do something more to get it accepted?

Thanks for your time.

----------

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

From report at bugs.python.org  Mon Dec  9 11:07:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 10:07:16 +0000
Subject: [docs] [issue18576] Rename and document test.script_helper
	as	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386583636.74.0.210535620246.issue18576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Please left test.script_helper as alias to test.support.script_helper.

I.e. test/script_helper.py should contains something like:

from test.support.script_helper import *

And test this with unmodifiable other tests.

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

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

From report at bugs.python.org  Mon Dec  9 12:13:13 2013
From: report at bugs.python.org (Fotis Koutoulakis)
Date: Mon, 09 Dec 2013 11:13:13 +0000
Subject: [docs] [issue18576] Rename and document test.script_helper
	as	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386587593.23.0.413131823195.issue18576@psf.upfronthosting.co.za>


Fotis Koutoulakis added the comment:

Ok, here is the second (modified patch) which contains a script so that no modifications are required to existing tests.

I am uploading it as a second patch, so that the first one is left as a reference.

As a sidenote, I fail to see convincing reasons for why we would want the second solution more than the first. The first one looks cleaner to my eyes. The only downside I can see to the original approach is breaking a couple of tests, which is something that can be fixed easily without even making it to the repo (running the tests in 2-3 could help find all possible broken tests beforehand).

Could someone explain to me why the second solution is more desirable?

----------
Added file: http://bugs.python.org/file33055/issue_18576_second.patch

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

From report at bugs.python.org  Mon Dec  9 12:44:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 11:44:46 +0000
Subject: [docs] [issue18576] Rename and document test.script_helper
	as	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386589485.95.0.584906383075.issue18576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Third party code can use tests.script_helper.

I prefer to do these changes in several steps:

1) Move script_helper.py to Lib/test/support/, document it, and create an alias (with deprecation warning).
2) Ensure that this doesn't break any buildbot.
3) Change tests to use test.support.script_helper instead of test.script_helper.
4) One or two versions later remove an alias.

----------

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

From report at bugs.python.org  Mon Dec  9 12:49:04 2013
From: report at bugs.python.org (Fotis Koutoulakis)
Date: Mon, 09 Dec 2013 11:49:04 +0000
Subject: [docs] [issue18576] Rename and document test.script_helper
	as	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386589744.8.0.198885528695.issue18576@psf.upfronthosting.co.za>


Fotis Koutoulakis added the comment:

Oh, I see. Does the last patch meet your expectations, or would you rather see all these changes implemented at once?

----------

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

From report at bugs.python.org  Mon Dec  9 13:04:29 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2013 12:04:29 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386590669.89.0.881694189595.issue19933@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks.  It's inaccurate to say that a float is returned in general, though:  for most builtin numeric types, what's returned has the same type as its input.  So rounding a Decimal to two places gives a Decimal on output, etc.  (That's already explained in the next paragraph.)

----------

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

From report at bugs.python.org  Mon Dec  9 13:06:37 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2013 12:06:37 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386590797.65.0.0572420085594.issue19933@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

How about just removing the mention of 'defaults to zero', and say something like: "if ndigits is omitted, returns the nearest int to its input"

----------

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

From storchaka at gmail.com  Mon Dec  9 13:16:55 2013
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Mon, 09 Dec 2013 12:16:55 -0000
Subject: [docs] Rename and document test.script_helper as
 test.support.script_helper (issue 18576)
Message-ID: <20131209121655.24456.39213@psf.upfronthosting.co.za>


http://bugs.python.org/review/18576/diff/10257/Doc/library/test.rst
File Doc/library/test.rst (right):

http://bugs.python.org/review/18576/diff/10257/Doc/library/test.rst#newcode615
Doc/library/test.rst:615: .. function::
test.support.script_helper._assert_python(expected_success, *args,
**env_vars)
This is private function and isn't used outside the module.

http://bugs.python.org/review/18576/diff/10257/Doc/library/test.rst#newcode621
Doc/library/test.rst:621: Assert that running the interpreter with
`args` and optional environment
*args*

And same for other parameters.

http://bugs.python.org/review/18576/diff/10257/Doc/library/test.rst#newcode622
Doc/library/test.rst:622: variables `env_vars` succeeds (rc == 0) and
return a (return code, stdout,
``rc == 0``

http://bugs.python.org/review/18576/diff/10257/Doc/library/test.rst#newcode625
Doc/library/test.rst:625: If the __cleanenv keyword is set, env_vars is
used a fresh environment.
*__cleanenv*

http://bugs.python.org/review/18576/diff/10257/Doc/library/test.rst#newcode627
Doc/library/test.rst:627: Python is started in isolated mode (command
line option -I),
``-I``

http://bugs.python.org/review/18576/diff/10257/Doc/library/test.rst#newcode628
Doc/library/test.rst:628: except if the __isolated keyword is set to
False.
*__isolated*

http://bugs.python.org/review/18576/diff/10257/Doc/library/test.rst#newcode633
Doc/library/test.rst:633: variables `env_vars` fails (rc != 0) and
return a (return code, stdout,
``rc != 0``

http://bugs.python.org/review/18576/diff/10257/Doc/library/test.rst#newcode656
Doc/library/test.rst:656: .. function::
test.support.script_helper.make_zip_pkg(zip_dir, zip_basename, pkg_name,
script_basename, source, depth=1, compiled=False)
Did you tried to use backslash for line continuation?

.. function:: test.support.script_helper.make_zip_pkg(zip_dir,
zip_basename, \
        pkg_name, script_basename, source, depth=1, compiled=False)

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

From report at bugs.python.org  Mon Dec  9 13:17:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 12:17:34 +0000
Subject: [docs] [issue18576] Rename and document test.script_helper
	as	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386591454.95.0.019856524284.issue18576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Does the last patch meet your expectations, or would you rather see all these changes implemented at once?

I left this for Nick.

I have added comments on Rietveld.

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

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

From report at bugs.python.org  Mon Dec  9 14:20:44 2013
From: report at bugs.python.org (Fotis Koutoulakis)
Date: Mon, 09 Dec 2013 13:20:44 +0000
Subject: [docs] [issue18576] Rename and document test.script_helper
	as	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386595244.49.0.635528703671.issue18576@psf.upfronthosting.co.za>


Fotis Koutoulakis added the comment:

Taking the feedback during code review, this is a patch that has the points raised by Serhiy Storchaka fixed.

As always, please do note omission or mistakes from my part. Thanks for your help.

----------
Added file: http://bugs.python.org/file33057/issue18576_third_try.patch

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

From report at bugs.python.org  Mon Dec  9 15:14:09 2013
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 09 Dec 2013 14:14:09 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386598449.67.0.511634331677.issue19933@psf.upfronthosting.co.za>


Jo?o Bernardo added the comment:

> I don't understand.  There's already a way to make round return an integer: don't pass a second argument.

If this function were to be written in Python, it would be something like:

    def round(number, ndigits=0):
        ...

or 

    def round(number, ndigits=None):
        ...


But in C you can forge the signature to whatever you want and parse the arguments accordingly. In Python there's always a way to get the default behavior by passing the default argument, but in C it may not exist (in this case `PyObject *o_ndigits = NULL;`)

So, I propose the default value being `None`, so this behavior can be achieved using a second argument.

----------

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

From report at bugs.python.org  Mon Dec  9 15:55:18 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 14:55:18 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386600918.07.0.174920229884.issue19933@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the updated doc fix.

Anyway, why not round(1.2) -> 1.0 in the first place? Just curious.

----------
Added file: http://bugs.python.org/file33060/fix_doc_round_ndigits_v2.patch

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

From report at bugs.python.org  Mon Dec  9 16:25:04 2013
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 09 Dec 2013 15:25:04 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386602704.78.0.239747003867.issue19933@psf.upfronthosting.co.za>


Jo?o Bernardo added the comment:

> Anyway, why not round(1.2) -> 1.0 in the first place? Just curious.

It was the behavior on Python 2.x, but somehow when they changed the rounding method to nearest even number this happened... I think it's too late to change back the return type.

----------

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

From report at bugs.python.org  Mon Dec  9 16:31:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Dec 2013 15:31:59 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386603119.18.0.58856989809.issue19933@psf.upfronthosting.co.za>


R. David Murray added the comment:

Do you have any real-world motivating use case for None?  Not just theoretical consistency with what a Python version of the function would look like.  (I'm not saying we shouldn't consider supporting None as a low priority change, I'm just trying to figure out where you'd ever need it in the real world.)

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

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

From report at bugs.python.org  Mon Dec  9 16:44:54 2013
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 09 Dec 2013 15:44:54 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386603894.77.0.509489130649.issue19933@psf.upfronthosting.co.za>


Jo?o Bernardo added the comment:

Not really. Just consistency:

For the same reason  

    ' foo '.strip(None)

works... To avoid special casing the function call when you already have a variable to hold the argument.

----------

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

From report at bugs.python.org  Mon Dec  9 17:06:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Dec 2013 16:06:47 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386605207.42.0.601593203606.issue19933@psf.upfronthosting.co.za>


R. David Murray added the comment:

Right, but None in that case has real world utility, since you might have the the value in a variable.  But you are hardly going to hold int-or-not in a variable, especially a variable that is really about the number of places in the float result...

----------

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

From report at bugs.python.org  Mon Dec  9 19:22:46 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 09 Dec 2013 18:22:46 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386613366.73.0.848067929507.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Sadly, the optimistic code doesn't work on Windows.  I think it may be because the socketpair() helper at the top of test_selectors.py uses an extra socket ('l') and the handles just don't match up (I get a failure on assert wr2.fileno() == w).  So I propose to stick with the current solution of skipping the test on Windows.

I'll close this bug in 24 hours unless I get a response sooner.

----------

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

From report at bugs.python.org  Mon Dec  9 19:24:58 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 18:24:58 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386613498.89.0.728788852701.issue19876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The current test using os.dup2() with a skip on Windows is fine.

----------

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

From report at bugs.python.org  Mon Dec  9 19:28:31 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 09 Dec 2013 18:28:31 +0000
Subject: [docs] [issue19876] selectors (and asyncio?): document behaviour on
	closed	files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386613711.14.0.0713252301896.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, closed.

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

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

From report at bugs.python.org  Mon Dec  9 20:07:00 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2013 19:07:00 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386616020.33.0.589382546901.issue19933@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Anyway, why not round(1.2) -> 1.0 in the first place? Just curious.

All this changed as part of PEP 3141.  I wasn't watching Python 3 development closely back then, but I *think* at least part of the motivation was to provide a way to get away from the use of `int` to truncate a float to its integer part:  the argument goes that a simple type conversion shouldn't throw away information, and that if you want a transformation from float to int that throws away information you should ask for it explicitly.  So `math.trunc` was born as the preferred way to truncate a float to an int, and `math.floor`, `math.ceil` and `round` became alternative float -> int conversion methods.  That entailed those functions returning ints.

<off-topic> In the case of `math.floor` and `math.ceil` at least, I think this is regrettable.  There are plenty of places where you just want a float -> float floor or ceiling, and Python no longer has a cheap operation for that available:  floor as a float-to-float operation is cheap;  floor as a float-to-long-integer operation is significantly more costly.

In the case of `round`, we still have `round(x, 0)` available as a cheap float->float conversion, so it's less of a problem.  And I hardly ever use `trunc`, so I don't care about that case. </off-topic>

----------

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

From report at bugs.python.org  Mon Dec  9 20:30:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 19:30:09 +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: <1386617409.08.0.729346307236.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

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

From report at bugs.python.org  Mon Dec  9 20:42:24 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2013 19:42:24 +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: <1386618144.26.0.742313745926.issue17576@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Ping.

Bah.  Sorry; I haven't had time to deal with this.  Serhiy: are you interested in taking over?

----------

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

From report at bugs.python.org  Mon Dec  9 23:44:38 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Dec 2013 22:44:38 +0000
Subject: [docs] [issue18576] Rename and document test.script_helper
	as	test.support.script_helper
In-Reply-To: <1386595244.49.0.635528703671.issue18576@psf.upfronthosting.co.za>
Message-ID: <CADiSq7f1c3HoOYtqLE8X0TEaMk94WgoLB1ZzrL4e-=fGBSfvhA@mail.gmail.com>


Nick Coghlan added the comment:

Note that the test.* namespace has long been declared as unstable, so we
don't worry about breaking third party code when rearranging the test suite
(as far as I am aware, most Linux distros don't even include the test suite
in their Python packages).

I'll see how Mercurial goes tracking the file move when the alias is left
behind, and decide which way to do the initial change based on whether or
not the alias breaks the history tracking.

----------

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

From report at bugs.python.org  Tue Dec 10 05:42:34 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 10 Dec 2013 04:42:34 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386650554.86.0.291083993428.issue19933@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

In case we want to add consistency with None ndigits, here is the patch adding support for None value for ndigits parameter.

This one looks like a low-risk addition but since Python 3.4 is in beta phase....

----------
Added file: http://bugs.python.org/file33074/fix_doc_ndigits_round_and_add_None_ndigits.patch

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

From report at bugs.python.org  Tue Dec 10 08:29:12 2013
From: report at bugs.python.org (akira)
Date: Tue, 10 Dec 2013 07:29:12 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
Message-ID: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>


New submission from akira:

cert_time_to_seconds() uses `time.mktime()` [1] to convert utc time tuple to seconds since epoch. `mktime()` works with local time. It should use `calendar.timegm()` analog instead.

Example from the docs [2] is seven hours off (it shows utc offset of the local timezone of the person who created it):

    >>> import ssl
    >>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")
    1178694000.0

It should be `1178668800`:

    >>> from datetime import datetime
    >>> datetime.utcfromtimestamp(1178668800)
    datetime.datetime(2007, 5, 9, 0, 0)
    >>> import time
    >>> time.gmtime(1178668800)
    time.struct_time(tm_year=2007, tm_mon=5, tm_mday=9, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=2, tm_yday=129, tm_isdst=0)


And `calendar.timegm` returns correct result:

    >>> calendar.timegm(time.strptime("May 9 00:00:00 2007 GMT", "%b %d %H:%M:%S %Y GMT"))
    1178668800

[1]: http://hg.python.org/cpython/file/96a68e369d13/Lib/ssl.py#l849
[2]: http://hg.python.org/cpython/file/96a68e369d13/Doc/library/ssl.rst#l359

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 205774
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Dec 10 12:47:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 11:47:31 +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: <1386676051.41.0.597248533587.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is updated patch. There is no more overhead in PyLong_As* functions. Simplified PyNumber_Index(). assertWarns() now used instead of support.check_warnings(). Added new tests.

----------
Added file: http://bugs.python.org/file33077/issue17576_v3.patch

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

From report at bugs.python.org  Tue Dec 10 13:02:03 2013
From: report at bugs.python.org (Tim Golden)
Date: Tue, 10 Dec 2013 12:02:03 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386676923.99.0.732236071479.issue19940@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
versions:  -Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Dec 10 13:09:03 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 12:09:03 +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: <1386677343.02.0.243206597746.issue17576@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Took me a while to figure out that one of the code paths was being deleted as redundant because the type machinery will always fill in nb_int for int subclasses, but Serhiy's patch looks good to me.

----------
assignee: mark.dickinson -> serhiy.storchaka

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

From report at bugs.python.org  Tue Dec 10 13:10:46 2013
From: report at bugs.python.org (gudge)
Date: Tue, 10 Dec 2013 12:10:46 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386677446.28.0.896231579325.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

Will work on this.
Please assign the issue to me.

Instructions before proceeding by Tim Golden(python mailing list):

Having just glanced at that issue, I would point out that there's been a
lot of development around the ssl module for the 3.4 release, so you
definitely want to confirm the issue against the hg tip to ensure it
still applies.

----------
nosy: +gudge

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

From report at bugs.python.org  Tue Dec 10 14:42:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Dec 2013 13:42:55 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386682975.52.0.579890063913.issue19940@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +christian.heimes, giampaolo.rodola, janssen, pitrou
versions:  -Python 2.7, Python 3.3, Python 3.5

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

From report at bugs.python.org  Tue Dec 10 14:43:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Dec 2013 13:43:08 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386682988.22.0.0538971530036.issue19940@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

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

From report at bugs.python.org  Tue Dec 10 14:46:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Dec 2013 13:46:54 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386683214.24.0.565982331159.issue19940@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Indeed the example in the docs is wrong, and so is the current behaviour.

The example shows "round-tripping" using ssl.cert_time_to_seconds() and then time.ctime(), except that it is bogus as it takes a GMT time and ctime() returns a local time ("""Convert a time expressed in seconds since the epoch to a string representing local time""").

Still, we should only fix it in 3.4, as code written for prior versions may rely on the current (bogus) behaviour.

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

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

From report at bugs.python.org  Tue Dec 10 14:48:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Dec 2013 13:48:14 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386683293.99.0.630527206823.issue19940@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

gudge, your contribution is welcome! If you need guidance about how to write a patch, you can read the developer's guide: http://docs.python.org/devguide/

Also you will have to sign a contributor's agreement: http://www.python.org/psf/contrib/

----------

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

From report at bugs.python.org  Tue Dec 10 21:04:07 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 10 Dec 2013 20:04:07 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386705847.68.0.077096738487.issue19940@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy:  -giampaolo.rodola

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

From report at bugs.python.org  Tue Dec 10 21:38:04 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 Dec 2013 20:38:04 +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: <1386707884.63.0.451380427475.issue17576@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks, Serhiy.

----------

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

From report at bugs.python.org  Tue Dec 10 22:37:28 2013
From: report at bugs.python.org (akira)
Date: Tue, 10 Dec 2013 21:37:28 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386711448.65.0.591865932318.issue19940@psf.upfronthosting.co.za>


akira added the comment:

gudge,

There is also an issue with the current strptime format [1] (`"%b %d %H:%M:%S %Y GMT"`). It is locale-dependent and it may fail if a non-English locale is in effect. I don't know whether I should open a new issue on this or are you going to fix it too.

`cert_time_to_seconds()` is documented [2] to parse notBefore, notAfter fields from a certificate. As far as I can tell they do not depend on current locale. Thus the following code should not fail:

    >>> timestr = "May  9 00:00:00 2007 GMT"
    >>> import ssl
    >>> ssl.cert_time_to_seconds(timestr)
    1178661600.0
    >>> import locale
    >>> locale.setlocale(locale.LC_TIME, 'pl_PL.utf8')
    'pl_PL.utf8'
    >>> ssl.cert_time_to_seconds(timestr)
    Traceback (most recent call last):
    ...[snip]...
    ValueError: time data 'May  9 00:00:00 2007 GMT' does not match format '%b %d %H:%M:%S %Y GMT'


[1]: http://hg.python.org/cpython/file/96a68e369d13/Lib/ssl.py#l849
[2]: http://hg.python.org/cpython/file/96a68e369d13/Doc/library/ssl.rst#l359

----------

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

From report at bugs.python.org  Tue Dec 10 22:53:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 21:53:32 +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: <1386712412.3.0.864751342793.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What about PyLong_AsSsize_t(), PyLong_AsUnsignedLong(), and PyLong_AsSize_t()? They are ignore __int__().

PyLong_AsVoidPtr() calls PyLong_AsLong(), PyLong_AsUnsignedLong(), PyLong_AsLongLong(), or PyLong_AsUnsignedLongLong() (depending on pointer's size and it's sign) and therefore can call or not call __int__, can raise or not raise TypeError on non-int subclasses with defined __int__().

----------

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

From report at bugs.python.org  Tue Dec 10 23:34:18 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 10 Dec 2013 22:34:18 +0000
Subject: [docs] [issue19950] Document that unittest.TestCase.__init__ is
	called once	per test
Message-ID: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

I was surprised that in the following __init__ is actually called once per test function, although nothing in documentation implied so.

a.py
------

import unittest

class A(unittest.TestCase):
   def __init__(self, *args, **kwargs):
       print('called only once!')
       super().__init__(*args, **kwargs)

   def test(self):
       self.assertEqual(1, 1)
 
   def test2(self):
       self.assertEqual(2, 2)

if __name__ == '__main__':
   unittest.main()

$ python a.py
called only once!
called only once!
..
----------------------------------------------------------------------
Ran 2 tests in 0.001s

OK



The attached patch adds a note regarding this behaviour for the TestCase class.

----------
assignee: docs at python
components: Documentation
files: unittest_init.patch
keywords: patch
messages: 205864
nosy: Claudiu.Popa, docs at python, michael.foord
priority: normal
severity: normal
status: open
title: Document that unittest.TestCase.__init__ is called once per test
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33086/unittest_init.patch

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

From report at bugs.python.org  Tue Dec 10 23:51:06 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Dec 2013 22:51:06 +0000
Subject: [docs] [issue19950] Document that unittest.TestCase.__init__ is
	called once	per test
In-Reply-To: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za>
Message-ID: <1386715866.35.0.843697996352.issue19950@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm guessing it is that a new TestCase instance is instantiated each time an individual test is run.  I don't know that this is part of the API, though, so I'm not sure how it should be documented.

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

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

From report at bugs.python.org  Wed Dec 11 00:00:59 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 10 Dec 2013 23:00:59 +0000
Subject: [docs] [issue19950] Document that unittest.TestCase.__init__ is
	called once	per test
In-Reply-To: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za>
Message-ID: <1386716459.39.0.138488876572.issue19950@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

This sentence seems to cover it: "Each instance of the TestCase will only be used to run a single test method, so a new fixture is created for each test."  from http://docs.python.org/2/library/unittest.html

The word "fixture" here is being used oddly, but that's the sentence.

----------
nosy: +nedbat

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

From report at bugs.python.org  Wed Dec 11 00:07:40 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 10 Dec 2013 23:07:40 +0000
Subject: [docs] [issue19950] Document that unittest.TestCase.__init__ is
	called once	per test
In-Reply-To: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za>
Message-ID: <1386716860.57.0.0674795974148.issue19950@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

"Each instance of the TestCase will only be used to run a single test method, so a new fixture is created for each test."

Yes, this seems to be, but it is not clear what fixture means in this context (as in "the preparation needed to perform one or *more* tests"?). Perhaps enhancing the message a little will suffice.

----------

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

From report at bugs.python.org  Wed Dec 11 00:11:10 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 23:11:10 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
	(or	operator.index() docos lie)
In-Reply-To: <1386712412.3.0.864751342793.issue17576@psf.upfronthosting.co.za>
Message-ID: <CADiSq7cNFAJLC_sFHrHw3ueb6_HzX_FXL3q=4jnFN5jScL455A@mail.gmail.com>


Nick Coghlan added the comment:

The ssize_t functions deliberately ignore lossy int conversions (e.g. from
floats) - that's why they only work on types that implement __index__.

----------

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

From report at bugs.python.org  Wed Dec 11 00:49:35 2013
From: report at bugs.python.org (Michael Foord)
Date: Tue, 10 Dec 2013 23:49:35 +0000
Subject: [docs] [issue19950] Document that unittest.TestCase.__init__ is
	called once	per test
In-Reply-To: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za>
Message-ID: <1386719375.49.0.891723459818.issue19950@psf.upfronthosting.co.za>


Michael Foord added the comment:

I'd be happy with a doc change from "fixture" to instance (or maybe add instance in parentheses). I'd rather a simple change than making the documentation much longer.

The reason for a separate instance per test is for test isolation. Each test can create and modify instance attributes without them affecting other tests from the same class.

----------

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

From report at bugs.python.org  Wed Dec 11 07:38:39 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 11 Dec 2013 06:38:39 +0000
Subject: [docs] [issue19710] Make sure documentation for PEP 451 is finished
In-Reply-To: <1385138705.49.0.0614847614933.issue19710@psf.upfronthosting.co.za>
Message-ID: <1386743919.6.0.699477720859.issue19710@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've attached a patch to issue19713 (file33088) that adds documentation for the new APIs.  Also, there were some good reviews in issue18864 (especially for file32381) that never got fully addressed.

----------

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

From report at bugs.python.org  Wed Dec 11 08:34:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 07:34:48 +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: <1386747288.28.0.756541927862.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> The ssize_t functions deliberately ignore lossy int conversions (e.g. from
> floats) - that's why they only work on types that implement __index__.

They ignore __index__.

----------

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

From report at bugs.python.org  Wed Dec 11 08:37:09 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 11 Dec 2013 07:37:09 +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: <1386747429.05.0.533730294119.issue17576@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Yes, the PyLong_As... conversions are a mess.  In theory, they should all use __index__ if available, and ignore __int__.  In practice, it's a mess that's difficult to change without breaking things.  I think there are already some other issues open on this subject.

----------

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

From report at bugs.python.org  Wed Dec 11 09:08:24 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Wed, 11 Dec 2013 08:08:24 +0000
Subject: [docs] [issue19950] Document that unittest.TestCase.__init__ is
	called once	per test
In-Reply-To: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za>
Message-ID: <1386749304.46.0.237838847029.issue19950@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

How about the following:

"Each instance of the TestCase will only be used to run a single test method from it, so a new instance is created for each test method."


It replaces `fixture` with `instance` and it emphasizes that the called method belongs to that particular TestCase instance.

----------

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

From report at bugs.python.org  Wed Dec 11 09:59:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 08:59:39 +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: <1386752379.75.0.81517086335.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PyLong_AsUnsignedLong() and PyLong_AsLong() can return different values for same object. Why __int__ and __index__ should be used for int subclasses at all? I'm not sure this is right solution.

----------

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

From report at bugs.python.org  Wed Dec 11 20:28:18 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Dec 2013 19:28:18 +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: <3dfp8L02D1z7Llb@mail.python.org>


Roundup Robot added the comment:

New changeset 618cca51a27e by Serhiy Storchaka in branch '3.3':
Issue #17576: Deprecation warning emitted now when __int__() or __index__()
http://hg.python.org/cpython/rev/618cca51a27e

New changeset 59fb79d0411e by Serhiy Storchaka in branch 'default':
Issue #17576: Deprecation warning emitted now when __int__() or __index__()
http://hg.python.org/cpython/rev/59fb79d0411e

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

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

From report at bugs.python.org  Wed Dec 11 21:02:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 20:02:12 +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: <1386792132.28.0.121459857512.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I first committed safe part of patch, which doesn't change behavior, only adds warnings and tests. Here is other part (very simple), which change behavior (in sum they are equal to issue17576_v3.patch with minor changes).

* PyNumber_Index() now calls __index__() for int subclasses.

>>> class A(int):
...     def __index__(self): return 1
... 
>>> import operator
>>> operator.index(A())

Returns 0 without patch and 1 with patch.

* PyNumber_Long() now calls __int__() on result of __trunc__() if it is int subclass instance.

>>> class A:
...     def __trunc__(self): return True
... 
>>> int(A())

Returns True without patch and 1 with patch.

* PyLong_As*() functions (but not all) call __int__() for int subclasses (I'm not sure this is right).

>>> class A(int):
...     def __int__(self): return 42
... 
>>> chr(A(43))

Returns '+' without patch and '*' with patch.

----------
Added file: http://bugs.python.org/file33093/issue17576_v4.patch

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

From report at bugs.python.org  Wed Dec 11 21:13:08 2013
From: report at bugs.python.org (ferno)
Date: Wed, 11 Dec 2013 20:13:08 +0000
Subject: [docs] [issue19953] __iadd__() doc not strictly correct
Message-ID: <1386792788.94.0.272007303341.issue19953@psf.upfronthosting.co.za>


New submission from ferno:

Document in question is:

    http://docs.python.org/3.3/reference/datamodel.html#object.__iadd__

The documentation states,

    to execute the statement x += y, where x is an instance of a class that has an __iadd__() method, x.__iadd__(y) is called.

However, this doesn't appear to be strictly true. According to this, the following well-known example:

    >>> a = (1, [2, 3])
    >>> a[1] += [4, 5]
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: 'tuple' object does not support item assignment
    >>> a
    (1, [2, 3, 4, 5])

should give the same behaviour as:

    >>> a = (1, [2, 3])
    >>> a[1].__iadd__([4, 5])
    [2, 3, 4, 5]
    >>> a
    (1, [2, 3, 4, 5])

However, this snippet DOES give the identical behaviour:

    >>> a = (1, [2, 3])
    >>> a[1] = a[1].__iadd__([4, 5])
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: 'tuple' object does not support item assignment
    >>> a
    (1, [2, 3, 4, 5])

which leads me to suggest that this line of the documentation should be adjusted to read:

    to execute the statement x += y, where x is an instance of a class that has an __iadd__() method, x = x.__iadd__(y) is called.

This fix would incidentally harmonise with the documentation for operator.iadd() et al., (http://docs.python.org/3.3/library/operator.html#operator.iadd), which had a similar problem but was corrected following issue 7259 (http://bugs.python.org/issue7259), now reading:

    a = iadd(a, b) is equivalent to a += b.

----------
assignee: docs at python
components: Documentation
messages: 205920
nosy: docs at python, ferno
priority: normal
severity: normal
status: open
title: __iadd__() doc not strictly correct
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Dec 11 21:20:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 20:20:57 +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: <1386793257.06.0.346996576714.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Even with last patch int() can return non-int:

>>> class A(int):
...     def __int__(self): return True
...     def __repr__(self): return '<A>'
... 
>>> class B:
...     def __int__(self): return A()
... 
>>> class C:
...     def __trunc__(self): return A()
... 
>>> int(B())
<A>
>>> int(C())
True

----------

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

From report at bugs.python.org  Wed Dec 11 22:48:04 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 11 Dec 2013 21:48:04 +0000
Subject: [docs] [issue19934] collections.Counter.most_common does not
	document `None`	as acceptable input.
In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za>
Message-ID: <1386798484.62.0.326835986209.issue19934@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Dec 12 22:16:13 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Dec 2013 21:16:13 +0000
Subject: [docs] [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1386882973.1.0.580949130324.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also the issue #19846.

----------

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

From report at bugs.python.org  Fri Dec 13 01:35:36 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 00:35:36 +0000
Subject: [docs] [issue19576] "Non-Python created threads" documentation
	doesn't	mention PyEval_InitThreads()
In-Reply-To: <1384379370.85.0.232061958171.issue19576@psf.upfronthosting.co.za>
Message-ID: <1386894936.2.0.972877939514.issue19576@psf.upfronthosting.co.za>


STINNER Victor added the comment:

So Antoine, what do you think of the fix?

----------

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

From report at bugs.python.org  Fri Dec 13 01:36:30 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Dec 2013 00:36:30 +0000
Subject: [docs] [issue19576] "Non-Python created threads" documentation
	doesn't	mention PyEval_InitThreads()
In-Reply-To: <1384379370.85.0.232061958171.issue19576@psf.upfronthosting.co.za>
Message-ID: <1386894990.27.0.974825151213.issue19576@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Looks good to me.

----------

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

From report at bugs.python.org  Fri Dec 13 01:48:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 00:48:00 +0000
Subject: [docs] [issue19576] "Non-Python created threads" documentation
	doesn't	mention PyEval_InitThreads()
In-Reply-To: <1384379370.85.0.232061958171.issue19576@psf.upfronthosting.co.za>
Message-ID: <3dgYBl2WqSz7LlP@mail.python.org>


Roundup Robot added the comment:

New changeset dc4e805ec68a by Victor Stinner in branch 'default':
Close #19576: PyGILState_Ensure() now initializes threads. At startup, Python
http://hg.python.org/cpython/rev/dc4e805ec68a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec 13 10:28:46 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 13 Dec 2013 09:28:46 +0000
Subject: [docs] [issue19970] Typo of `immediatly` and `agin` words
Message-ID: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

ethan at amiau:~/Documents/code/python/cpython3.4$ grep -R immediatly *
Doc/library/asyncio-protocol.rst::meth:`Transport.close` can be called immediatly after
Lib/test/test_signal.py:            # unblock the pending signal calls immediatly the signal handler
Modules/faulthandler.c:    /* call the previous signal handler: it is called immediatly if we use
ethan at amiau:~/Documents/code/python/cpython3.4$ grep -R " agin " *
Modules/posixmodule.c:           the symlink path agin and not the actual final path. */
Modules/posixmodule.c:           the symlink path agin and not the actual final path. */

----------
assignee: docs at python
components: Documentation, Extension Modules, Library (Lib)
files: fix_typo_agin_and_immediatly_python34.patch
keywords: patch
messages: 206031
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Typo of `immediatly` and `agin` words
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33114/fix_typo_agin_and_immediatly_python34.patch

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

From report at bugs.python.org  Fri Dec 13 10:28:57 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 13 Dec 2013 09:28:57 +0000
Subject: [docs] [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <1386926937.74.0.475420722454.issue19970@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file33115/fix_typo_agin_and_immediatly_python33.patch

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

From report at bugs.python.org  Fri Dec 13 10:54:50 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 13 Dec 2013 09:54:50 +0000
Subject: [docs] [issue19971] Remove Tulip words from asyncio
	documentation/code
Message-ID: <1386928490.02.0.72947185095.issue19971@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

I was reading the documentation about asyncio. Here is the introduction paragraph:

Doc/library/asyncio.rst
=======================

This module provides infrastructure for writing single-threaded concurrent
code using coroutines, multiplexing I/O access over sockets and other
resources, running network clients and servers, and other related primitives.
Here is a more detailed list of the package contents:

Then I read it like a novel. Then somewhere out of the blue, the Tulip word shows up.

Doc/library/asyncio-sync.rst
============================

Unlike the standard library :mod:`queue`, you can reliably know this Queue's
   size with :meth:`qsize`, since your single-threaded Tulip application won't
   be interrupted between calling :meth:`qsize` and doing an operation on the
   Queue.

The Tulip word breaks the flow of the story because we never introduce the Tulip word previously. There are two ways to handle this situation:
1. Introduce the Tulip word in the introduction and other parts consistently,
2. Remove the references to Tulip.

I suggest we take option 2 (users of Python 3.4 asyncio stdlib have no reason to know the word Tulip). Here is the patch.

----------
assignee: docs at python
components: Documentation
files: remove_Tulip.patch
keywords: patch
messages: 206036
nosy: docs at python, gvanrossum, vajrasky
priority: normal
severity: normal
status: open
title: Remove Tulip words from asyncio documentation/code
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33117/remove_Tulip.patch

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

From report at bugs.python.org  Fri Dec 13 10:59:19 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 09:59:19 +0000
Subject: [docs] [issue19971] Remove Tulip words from asyncio
	documentation/code
In-Reply-To: <1386928490.02.0.72947185095.issue19971@psf.upfronthosting.co.za>
Message-ID: <1386928759.1.0.159179341652.issue19971@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I agree to drop references to the Tulip name. Thanks for your patch.

changeset:   87927:10378199e37b
tag:         tip
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Fri Dec 13 10:57:04 2013 +0100
files:       Doc/library/asyncio-sync.rst Doc/whatsnew/3.4.rst Lib/asyncio/queues.py Lib/asyncio/test_utils.py
description:
asyncio: remove references to the Tulip project, rename Tulip to asyncio.
Patch written by Vajrasky Kok.

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Dec 13 11:24:56 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 10:24:56 +0000
Subject: [docs] [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1386930296.94.0.238992952844.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm closing this issue as invalid for the same reason than I closed the issue #19846:
http://bugs.python.org/issue19846#msg205675

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Dec 13 17:41:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 16:41:09 +0000
Subject: [docs] [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1386952869.24.0.983850262819.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I created the issue #19977 as a follow up of this one: "Use surrogateescape error handler for sys.stdout on UNIX for the C locale".

----------

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

From report at bugs.python.org  Sat Dec 14 02:34:52 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Dec 2013 01:34:52 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
Message-ID: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

>>> help(1)
# help on int
>>> help(b'a')
# help on bytes
>>> help('a')
no Python documentation found for 'a'

The reason for this unhelpful response is that strings are treated differently from all other non-class objects. (msg205861 thought this a bug.) The strings value is matched against strings that would be recognized at the help> prompt given after help().

>>> help('topics')
# list of TOPICS
>>> help('LISTS')
# information about mutable sequences

Suggestion: add something more about what to do. Example enhanced response:

No Python documentation found for 'a'. Try help('help') for information on recognized strings or help(str) for help on the str class.

I believe this could be backported since help() is intented for interactive use only.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 206157
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve help('non-topic') response
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec 14 02:35:29 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Dec 2013 01:35:29 +0000
Subject: [docs] [issue18918] help('FILES') finds no documentation
In-Reply-To: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za>
Message-ID: <1386984929.19.0.543567564848.issue18918@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec 14 02:47:06 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 14 Dec 2013 01:47:06 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1386985626.39.0.399504790951.issue19980@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

IMHO this must be changed.

>>> help('')
# nothing!!!
>>> help('a')
Help on module a:

...

I happened to have a module called a.py in the default directory.

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

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

From report at bugs.python.org  Sat Dec 14 02:54:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Dec 2013 01:54:16 +0000
Subject: [docs] [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <3dhBck1nG7z7LkT@mail.python.org>


Roundup Robot added the comment:

New changeset 8e18a3b54bbe by R David Murray in branch '3.3':
#19970: Fix some comment typos.
http://hg.python.org/cpython/rev/8e18a3b54bbe

New changeset 358a35471f9f by R David Murray in branch 'default':
Merge: #19970: Fix some comment typos.
http://hg.python.org/cpython/rev/358a35471f9f

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

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

From report at bugs.python.org  Sat Dec 14 02:59:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Dec 2013 01:59:01 +0000
Subject: [docs] [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <1386986341.12.0.244919792549.issue19970@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Vajrasky.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Dec 14 03:18:07 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Dec 2013 02:18:07 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386987487.54.0.8494253872.issue19933@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The docstring is better than the current doc as it says that the default precision is 0, without calling that the default for ndigits.

''' round(number[, ndigits]) -> number
    
    Round a number to a given precision in decimal digits (default 0 digits).
    This returns an int when called with one argument, otherwise the
    same type as the number. ndigits may be negative.'''

---
Sidenote: To write round in Python, one could easily write

_sentinel = object
def round(number, ndigits=_sentinel):
  if ndigits is _sentinel: ...

which makes ndigits positional-or-keyword, and almost optional-with-no-default, as _sentinel is close enough to being a default that cannot be passed in. This is a standard idiom. One who was really picky about having no default could use
  def round(number, *args, **kwds): ...
and look for len(args) == 1 xor kwds.keys() == {'ndigits'}.

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

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

From report at bugs.python.org  Sat Dec 14 03:55:31 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Dec 2013 02:55:31 +0000
Subject: [docs] [issue19953] __iadd__() doc not strictly correct
In-Reply-To: <1386792788.94.0.272007303341.issue19953@psf.upfronthosting.co.za>
Message-ID: <1386989731.39.0.597709518015.issue19953@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The current doc is correct. Unlike the old incorrect version of the operator doc (#7259), it does not say that the call is all of the execution. The suggested replacement "x = x.__iadd__(y) is called" is not correct as statements are not called.

The said, it seems that some people miss the fact that augmented assignment always does an assignment. So, considering that the first sentence of the paragraph, "These methods are called to implement the augmented arithmetic assignments (+=, -=, *=, /=, //=, %=, **=, <<=, >>=, &=, ^=, |=)." already talks about calling, I thing

"For instance, to execute the statement x += y, where x is an instance of a class that has an __iadd__() method, x.__iadd__(y) is called. If x is an instance of a class that does not define a __iadd__() method, x.__add__(y) and y.__radd__(x) are considered, as with the evaluation of x + y."

might be replaced by

"For instance, if x is an instance of a class with an __iadd__() method, x += y is equivalent to x = x.__iadd__(y) . Otherwise, x.__add__(y) and y.__radd__(x) are considered, as with the evaluation of x + y."

----------
keywords: +patch
nosy: +terry.reedy
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

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

From report at bugs.python.org  Sat Dec 14 06:17:34 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 14 Dec 2013 05:17:34 +0000
Subject: [docs] [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <1386998253.97.0.251311997048.issue19970@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

R. David Murray, there is a reason I create separate patches for 3.3 and 3.4. You couldn't just merge them. Python 3.4 has additional file with typo, which is immediatly in Doc/library/asyncio-protocol.rst. :)

----------

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

From report at bugs.python.org  Sat Dec 14 07:55:45 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 14 Dec 2013 06:55:45 +0000
Subject: [docs] [issue16355] inspect.getcomments() does not work in the
	interactive	shell
In-Reply-To: <1351511930.82.0.59071323276.issue16355@psf.upfronthosting.co.za>
Message-ID: <1387004145.36.0.963732616879.issue16355@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

So, I just found out that imp has been deprecated. Here is the patch that uses importlib.machinery instead of imp.load_source.

----------
Added file: http://bugs.python.org/file33127/issue16355_v5.diff

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

From report at bugs.python.org  Sat Dec 14 09:39:28 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 Dec 2013 08:39:28 +0000
Subject: [docs] [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1387010367.96.0.595652784133.issue17259@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> From what I read in the thread it seems to be more like a bug rather than
> something to just be documented, right?

No, both round and formatting are working as expected: it's just a bit unfortunate that they use different rounding modes in 2.x.  It's not something that it would make sense to change in 2.7 at this stage---any such change would likely break a lot of code.

----------

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

From report at bugs.python.org  Sat Dec 14 09:42:34 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 Dec 2013 08:42:34 +0000
Subject: [docs] [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1387010554.1.0.0434731375302.issue17259@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

And the Python 2 behaviour has been essentially unchanged for a long time:

Python 2.4.6 (#1, Nov  7 2013, 16:01:20) 
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> "%.f %.f" % (0.5, 1.5)
'0 2'
>>> round(0.5), round(1.5)
(1.0, 2.0)

(Though that first call just shows the result of whatever the OS C libraries decide to do, but historically that seems to be more likely to be round-half-to-even than anything else.)

----------

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

From report at bugs.python.org  Sat Dec 14 10:47:14 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sat, 14 Dec 2013 09:47:14 +0000
Subject: [docs] [issue19981] Typo in mailbox documentation
Message-ID: <1387014434.61.0.267929363323.issue19981@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

In the last example, there is a misspelled imported module.

----------
assignee: docs at python
components: Documentation
files: mailbox_typo.patch
keywords: patch
messages: 206174
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Typo in mailbox documentation
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33130/mailbox_typo.patch

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

From report at bugs.python.org  Sat Dec 14 11:43:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Dec 2013 10:43:35 +0000
Subject: [docs] [issue19981] Typo in mailbox documentation
In-Reply-To: <1387014434.61.0.267929363323.issue19981@psf.upfronthosting.co.za>
Message-ID: <3dhQMV6pWyz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset 31fd129960d5 by Ezio Melotti in branch '2.7':
#19981: fix typo in email.mailbox docs.  Patch by Claudiu Popa.
http://hg.python.org/cpython/rev/31fd129960d5

New changeset 364ca376956f by Ezio Melotti in branch '3.3':
#19981: fix typo in email.mailbox docs.  Patch by Claudiu Popa.
http://hg.python.org/cpython/rev/364ca376956f

New changeset 0d8fe7d688a9 by Ezio Melotti in branch 'default':
#19981: merge with 3.3.
http://hg.python.org/cpython/rev/0d8fe7d688a9

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

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

From report at bugs.python.org  Sat Dec 14 11:44:12 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Dec 2013 10:44:12 +0000
Subject: [docs] [issue19981] Typo in mailbox documentation
In-Reply-To: <1387014434.61.0.267929363323.issue19981@psf.upfronthosting.co.za>
Message-ID: <1387017852.06.0.956239219143.issue19981@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Dec 14 17:21:56 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Dec 2013 16:21:56 +0000
Subject: [docs] [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <1387038116.85.0.262356652536.issue19970@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, well, it would be good to note that in the issue comments, then :).

The commit workflow is that a patch gets applied to a branch, then merged forward.  So I would need to apply the additional changes by hand to 3.4, unless you provide a 3.4 diff that is a diff between the *merged* 3.3 changeset and the updated 3.4 changes.  

Either way, let the committer know in the comments.  (I'll fix this momentarily.)

----------

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

From report at bugs.python.org  Sat Dec 14 17:23:13 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Dec 2013 16:23:13 +0000
Subject: [docs] [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <1387038193.19.0.863660410598.issue19970@psf.upfronthosting.co.za>


R. David Murray added the comment:

s/need/prefer/, unless the differences between the two patchsets are large, in which case I'd probably do a null merge followed by a separate 3.4 commit.

----------

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

From report at bugs.python.org  Sat Dec 14 17:26:22 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Dec 2013 16:26:22 +0000
Subject: [docs] [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <3dhYz20D8Bz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 561822250761 by R David Murray in branch 'default':
#19970: fix additional typo in 3.4 asyncio docs.
http://hg.python.org/cpython/rev/561822250761

----------

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

From report at bugs.python.org  Sat Dec 14 20:08:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Dec 2013 19:08:20 +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: <3dhdYw00G0z7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset a3de2b3881c1 by Serhiy Storchaka in branch '3.3':
Issue #17576: Removed deprecation warnings added in changeset 618cca51a27e.
http://hg.python.org/cpython/rev/a3de2b3881c1

----------

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

From report at bugs.python.org  Mon Dec 16 02:52:40 2013
From: report at bugs.python.org (Thayne McCombs)
Date: Mon, 16 Dec 2013 01:52:40 +0000
Subject: [docs] [issue19992] subprocess documentation not explicit about
	fileno()
Message-ID: <1387158760.79.0.499761911724.issue19992@psf.upfronthosting.co.za>


New submission from Thayne McCombs:

The subprocess documentation for stdout/stderr/stdin states: 
"Valid values are PIPE, an existing file descriptor (a positive integer), an existing file object, and None. PIPE indicates that a new pipe to the child should be created."

However, file-like objects such as StringIO are not valid if they do not implement fileno(). The documentation should be more explicit that the file object should be backed by an actual file descriptor (and therefore has a fileno() function).

----------
assignee: docs at python
components: Documentation
messages: 206272
nosy: Thayne.McCombs, docs at python
priority: normal
severity: normal
status: open
title: subprocess documentation not explicit about fileno()

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

From report at bugs.python.org  Mon Dec 16 09:42:52 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 16 Dec 2013 08:42:52 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1387183372.45.0.389760969029.issue19871@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

How about this doc fix?

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file33159/fix_doc_parse_non_valid_json_float.patch

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

From report at bugs.python.org  Mon Dec 16 11:44:22 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 16 Dec 2013 10:44:22 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1387190662.29.0.10604504753.issue19871@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Okay, I added unit test for this edge case.

----------
Added file: http://bugs.python.org/file33160/parse_non_valid_json_float_with_unit_test.patch

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

From report at bugs.python.org  Mon Dec 16 20:18:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 19:18:58 +0000
Subject: [docs] [issue20001] pathlib inheritance diagram too large
Message-ID: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The inheritance diagram at http://docs.python.org/dev/library/pathlib.html is too large, it can easily take up half the vertical space (or perhaps all of it on a smaller screen).

The font size looks fine, it's just that there's a lot of spacing around.
(of course, the style could perhaps also be changed or improved)

----------
assignee: docs at python
components: Documentation
messages: 206354
nosy: docs at python, eli.bendersky, georg.brandl, pitrou
priority: low
severity: normal
status: open
title: pathlib inheritance diagram too large
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 16 23:28:30 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 16 Dec 2013 22:28:30 +0000
Subject: [docs] [issue20001] pathlib inheritance diagram too large
In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za>
Message-ID: <1387232909.92.0.481488619726.issue20001@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

The source for the diagram is here: https://docs.google.com/drawings/d/1F8do-1WL1sIGkZuiufcxcpZRtS0w4SwAowq-Uamrwt8/edit?usp=sharing

Anyone - feel free to copy that doc over and create a new diagram with smaller whitespacing. Let me know if there are any problem accessing the doc.

----------

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

From report at bugs.python.org  Mon Dec 16 23:29:30 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 22:29:30 +0000
Subject: [docs] [issue20001] pathlib inheritance diagram too large
In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za>
Message-ID: <1387232970.28.0.756240520574.issue20001@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Please include the SVG source of the diagram in the Python source code, so the picture can be regenerated.

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

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

From report at bugs.python.org  Tue Dec 17 04:47:53 2013
From: report at bugs.python.org (rurpy)
Date: Tue, 17 Dec 2013 03:47:53 +0000
Subject: [docs] [issue20003] Language Ref "raise" doc misssing "from None"
Message-ID: <1387252072.89.0.572943909834.issue20003@psf.upfronthosting.co.za>


New submission from rurpy:

In the current (3.3.3 and 3.4dev) Language Reference Manual, the section on the Raise statement fails to mention that the second expression can be None (per PEP-409/415) or the special behavior (suppressing a chained exception) that ensues.  Rather it explicitly states it can not be None:
 "...the second expression must be another exception class  or instance..."

It appears that although the Exceptions section of the Library Reference was updated when PEP-409/415 was implemented, the Language Reference was not.

----------
assignee: docs at python
components: Documentation
messages: 206400
nosy: docs at python, rurpy2
priority: normal
severity: normal
status: open
title: Language Ref "raise" doc misssing "from None"
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec 17 06:13:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Dec 2013 05:13:41 +0000
Subject: [docs] [issue20001] pathlib inheritance diagram too large
In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za>
Message-ID: <3dk6vR1hVRz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset fe49ed665190 by Eli Bendersky in branch 'default':
Issue #20001: Add the SVG source of the pathlib-inheritance diagram to Hg
http://hg.python.org/cpython/rev/fe49ed665190

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

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

From report at bugs.python.org  Tue Dec 17 07:12:53 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2013 06:12:53 +0000
Subject: [docs] [issue19710] Make sure documentation for PEP 451 is finished
In-Reply-To: <1385138705.49.0.0614847614933.issue19710@psf.upfronthosting.co.za>
Message-ID: <1387260773.74.0.640815013966.issue19710@psf.upfronthosting.co.za>


Eric Snow added the comment:

New changeset 2c27c0e5bc50 by Eric Snow in branch 'default':
Issue #19713: Update importlib docs for module spec changes, including deprecations.
http://hg.python.org/cpython/rev/2c27c0e5bc50

New changeset b78de8029606 by Eric Snow in branch 'default':
Issue #19713: Fix mistakes in the import page of language reference.
http://hg.python.org/cpython/rev/b78de8029606

----------

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

From report at bugs.python.org  Tue Dec 17 07:13:27 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2013 06:13:27 +0000
Subject: [docs] [issue19710] Make sure documentation for PEP 451 is finished
In-Reply-To: <1385138705.49.0.0614847614933.issue19710@psf.upfronthosting.co.za>
Message-ID: <1387260807.53.0.055600841689.issue19710@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending
type:  -> enhancement

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

From report at bugs.python.org  Tue Dec 17 07:16:23 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2013 06:16:23 +0000
Subject: [docs] [issue19710] Make sure documentation for PEP 451 is finished
In-Reply-To: <1385138705.49.0.0614847614933.issue19710@psf.upfronthosting.co.za>
Message-ID: <1387260983.89.0.964021882959.issue19710@psf.upfronthosting.co.za>


Eric Snow added the comment:

I'm leaving this as pending for the moment in case we notice anything I missed.

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

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

From report at bugs.python.org  Tue Dec 17 07:26:07 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2013 06:26:07 +0000
Subject: [docs] [issue19710] Make sure documentation for PEP 451 is finished
In-Reply-To: <1385138705.49.0.0614847614933.issue19710@psf.upfronthosting.co.za>
Message-ID: <1387261567.61.0.241178819686.issue19710@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


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

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

From report at bugs.python.org  Tue Dec 17 09:30:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 08:30:45 +0000
Subject: [docs] [issue19894] zipfile ignores deflate level settings in
	zipinfo object
In-Reply-To: <1386235609.47.0.431866049959.issue19894@psf.upfronthosting.co.za>
Message-ID: <1387269045.78.0.969354840409.issue19894@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is new feature and can be added only in 3.5.

----------
assignee: docs at python -> 
components:  -Documentation, Tests
stage: patch review -> needs patch
type: behavior -> enhancement
versions: +Python 3.5 -Python 2.7

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

From report at bugs.python.org  Tue Dec 17 13:26:35 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 17 Dec 2013 12:26:35 +0000
Subject: [docs] [issue20005] Minor typo in operator documentation
Message-ID: <1387283195.71.0.0757941230254.issue20005@psf.upfronthosting.co.za>


Changes by Claudiu.Popa <pcmanticore at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: typo_operator.patch
keywords: patch
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Minor typo in operator documentation
versions: Python 3.4
Added file: http://bugs.python.org/file33176/typo_operator.patch

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

From report at bugs.python.org  Tue Dec 17 14:15:18 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Dec 2013 13:15:18 +0000
Subject: [docs] [issue16404] Uses of PyLong_FromLong that don't check for
	errors
In-Reply-To: <1352041027.23.0.922968343734.issue16404@psf.upfronthosting.co.za>
Message-ID: <3dkKb9721nz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset debdfa44f020 by Serhiy Storchaka in branch '2.7':
Issue #16404: Add checks for return value of PyInt_FromLong() in
http://hg.python.org/cpython/rev/debdfa44f020

New changeset 928c0acf7c09 by Serhiy Storchaka in branch '3.3':
Issue #16404: Add checks for return value of PyLong_FromLong() in
http://hg.python.org/cpython/rev/928c0acf7c09

New changeset d489394a73de by Serhiy Storchaka in branch 'default':
Issue #16404: Add checks for return value of PyLong_FromLong() in
http://hg.python.org/cpython/rev/d489394a73de

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

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

From report at bugs.python.org  Tue Dec 17 14:17:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 13:17:54 +0000
Subject: [docs] [issue16404] Uses of PyLong_FromLong that don't check for
	errors
In-Reply-To: <1352041027.23.0.922968343734.issue16404@psf.upfronthosting.co.za>
Message-ID: <1387286274.96.0.811756650158.issue16404@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage: patch review -> committed/rejected

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

From report at bugs.python.org  Tue Dec 17 17:29:46 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2013 16:29:46 +0000
Subject: [docs] [issue20004] csv.DictReader classic class has a property
	with setter
In-Reply-To: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>
Message-ID: <1387297786.75.0.483961552617.issue20004@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since it isn't easy to figure out that setting fieldnames to None would do anything useful without looking at the code, I'd say a code comment would be appropriate.  The exception would be someone backporting code from python3, but I think we'll just quietly ignore that possibility ;)

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

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

From report at bugs.python.org  Tue Dec 17 17:36:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2013 16:36:22 +0000
Subject: [docs] [issue20004] csv.DictReader classic class has a property
	with setter
In-Reply-To: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>
Message-ID: <1387298182.06.0.534425806263.issue20004@psf.upfronthosting.co.za>


R. David Murray added the comment:

Here is a proposed comment wording.

----------
keywords: +patch
Added file: http://bugs.python.org/file33181/csv_dictread_setter_comment.patch

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

From report at bugs.python.org  Tue Dec 17 17:52:05 2013
From: report at bugs.python.org (Peter Otten)
Date: Tue, 17 Dec 2013 16:52:05 +0000
Subject: [docs] [issue20004] csv.DictReader classic class has a property
	with setter
In-Reply-To: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>
Message-ID: <1387299125.25.0.411169090556.issue20004@psf.upfronthosting.co.za>


Peter Otten added the comment:

The proposed patch looks fine to me.

And for the record, I don't think setting fieldnames should be promoted in the 3.x documentation. Along the lines of Eric's suggestion I should have written something like

>>> import csv
>>> with open("tmp.csv") as f:
...     for i in range(2):
...             print next(csv.DictReader(f))
... 
{'alpha': '1', 'beta': '2'}
{'epsilon': '5', 'gamma': '3', 'delta': '4'}

which would have spared you the hustle ;)

Thank you for your effort!

----------

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

From report at bugs.python.org  Tue Dec 17 18:11:52 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2013 17:11:52 +0000
Subject: [docs] [issue20004] csv.DictReader classic class has a property
	with setter
In-Reply-To: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>
Message-ID: <1387300311.96.0.472038170499.issue20004@psf.upfronthosting.co.za>


R. David Murray added the comment:

Committed.  Thanks, Peter.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Dec 17 22:21:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 21:21:52 +0000
Subject: [docs] [issue16404] Uses of PyLong_FromLong that don't check for
	errors
In-Reply-To: <1352041027.23.0.922968343734.issue16404@psf.upfronthosting.co.za>
Message-ID: <1387315312.68.0.204566049618.issue16404@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Dec 18 13:35:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Dec 2013 12:35:02 +0000
Subject: [docs] [issue18576] Rename and document test.script_helper
	as	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1387370101.93.0.168970945221.issue18576@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The attached patch just moves the file without leaving an alias behind. It turns out we use this one in a fair few places (mostly for "assert_python_ok").

I'm going to sit on this change for the moment - after reading the docs, it's quite clear that the last couple of functions don't really belong in script_helper, but rather in the pkg_helper module discussed in issue 15376.

So my current plan is to factor that helper out *first*, then when this one lands, the intent of grouping more of the support code that folks working on the test suite might be interested in using together will hopefully be clearer.

----------
dependencies: +Refactor the test_runpy walk_package support code into a common location
Added file: http://bugs.python.org/file33188/issue18576_move_and_document_script_helper.diff

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

From report at bugs.python.org  Wed Dec 18 19:22:49 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Dec 2013 18:22:49 +0000
Subject: [docs] [issue20005] Minor typo in operator documentation
Message-ID: <3dl4MX2Yfgz7LjW@mail.python.org>


New submission from Roundup Robot:

New changeset f0eed36bab4c by Zachary Ware in branch '2.7':
Issue #20005: Fix typo in operator docs.  Patch by Claudiu Popa.
http://hg.python.org/cpython/rev/f0eed36bab4c

New changeset 17244b5df8b6 by Zachary Ware in branch '3.3':
Issue #20005: Fix typo in operator docs.  Patch by Claudiu Popa.
http://hg.python.org/cpython/rev/17244b5df8b6

New changeset a4a00e220e08 by Zachary Ware in branch 'default':
Closes #20005: Fix typo in operator docs.  Patch by Claudiu Popa.
http://hg.python.org/cpython/rev/a4a00e220e08

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Dec 18 19:23:31 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 18 Dec 2013 18:23:31 +0000
Subject: [docs] [issue20005] Minor typo in operator documentation
In-Reply-To: <3dl4MX2Yfgz7LjW@mail.python.org>
Message-ID: <1387391011.32.0.320953858545.issue20005@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the report and patch!

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

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

From report at bugs.python.org  Wed Dec 18 19:52:35 2013
From: report at bugs.python.org (Jeroen Van Goey)
Date: Wed, 18 Dec 2013 18:52:35 +0000
Subject: [docs] [issue20018] Replace dead URL with link to mirror
Message-ID: <1387392755.61.0.550067417471.issue20018@psf.upfronthosting.co.za>


New submission from Jeroen Van Goey:

The header of a cookie file generated by _MozillaCookieJar.py contains a link to the spec: http://www.netscape.com/newsref/std/cookie_spec.html

This URL no longer exists (redirects to the AOL homepage). Attached patch replaces the link with a mirror where the original text is hosted.

----------
assignee: docs at python
components: Documentation
files: _MozillaCookieJar.diff
keywords: patch
messages: 206549
nosy: docs at python, jeroen-vangoey, loewis
priority: normal
severity: normal
status: open
title: Replace dead URL with link to mirror
type: enhancement
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file33196/_MozillaCookieJar.diff

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

From report at bugs.python.org  Wed Dec 18 19:53:25 2013
From: report at bugs.python.org (Jeroen Van Goey)
Date: Wed, 18 Dec 2013 18:53:25 +0000
Subject: [docs] [issue20018] Replace dead URL with link to mirror
In-Reply-To: <1387392755.61.0.550067417471.issue20018@psf.upfronthosting.co.za>
Message-ID: <1387392805.85.0.293241071654.issue20018@psf.upfronthosting.co.za>


Jeroen Van Goey added the comment:

Added patch file for Python 3.3

----------
Added file: http://bugs.python.org/file33197/cookiejar.diff

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

From report at bugs.python.org  Wed Dec 18 22:36:38 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 18 Dec 2013 21:36:38 +0000
Subject: [docs] [issue19902] logging docs don't document integer constants
In-Reply-To: <1386285391.99.0.345532984259.issue19902@psf.upfronthosting.co.za>
Message-ID: <1387402597.89.0.361188030875.issue19902@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

The levels are documented here:

http://docs.python.org/howto/logging.html#logging-levels

----------
nosy: +vinay.sajip
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Wed Dec 18 22:37:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Dec 2013 21:37:19 +0000
Subject: [docs] [issue20018] Replace dead URL with link to mirror
In-Reply-To: <1387392755.61.0.550067417471.issue20018@psf.upfronthosting.co.za>
Message-ID: <3dl8gy53ZXz7Lk8@mail.python.org>


Roundup Robot added the comment:

New changeset 656a40666937 by Benjamin Peterson in branch '3.3':
update url to spec (closes #20018)
http://hg.python.org/cpython/rev/656a40666937

New changeset c0dc1400866a by Benjamin Peterson in branch '2.7':
update url to spec (closes #20018)
http://hg.python.org/cpython/rev/c0dc1400866a

New changeset 5f5e1d408c0c by Benjamin Peterson in branch 'default':
merge 3.3 (#20018)
http://hg.python.org/cpython/rev/5f5e1d408c0c

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Dec 19 07:10:18 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 06:10:18 +0000
Subject: [docs] [issue19710] Make sure documentation for PEP 451 is finished
In-Reply-To: <1385138705.49.0.0614847614933.issue19710@psf.upfronthosting.co.za>
Message-ID: <1387433418.33.0.93447602486.issue19710@psf.upfronthosting.co.za>


Eric Snow added the comment:

If anyone notices any issues with the doc changes, please open a new issue.

----------
status: pending -> closed

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

From report at bugs.python.org  Thu Dec 19 08:31:56 2013
From: report at bugs.python.org (follower)
Date: Thu, 19 Dec 2013 07:31:56 +0000
Subject: [docs] [issue19902] logging docs don't document integer constants
In-Reply-To: <1386285391.99.0.345532984259.issue19902@psf.upfronthosting.co.za>
Message-ID: <1387438316.43.0.832997757743.issue19902@psf.upfronthosting.co.za>


follower added the comment:

Thanks for pointing out that link. It's good to know the information is documented somewhere.

However, given that <http://docs.python.org/2/library/logging.html> is described as "the API reference" and seems to be the canonical logging library reference (rather than a tutorial) it would be appropriate to--and I would expect it to--include the constants information in it.

Thus I would request you reconsider the "invalid" resolution on this basis. Thanks.

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

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

From report at bugs.python.org  Thu Dec 19 12:51:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Dec 2013 11:51:34 +0000
Subject: [docs] [issue19902] logging docs don't document integer constants
In-Reply-To: <1386285391.99.0.345532984259.issue19902@psf.upfronthosting.co.za>
Message-ID: <3dlWdd5vzbz7Lk8@mail.python.org>


Roundup Robot added the comment:

New changeset 16bfddf5a091 by Vinay Sajip in branch '2.7':
Issue #19902: Added list of logging levels.
http://hg.python.org/cpython/rev/16bfddf5a091

New changeset e812094d42f9 by Vinay Sajip in branch '3.3':
Issue #19902: Added list of logging levels.
http://hg.python.org/cpython/rev/e812094d42f9

New changeset 45bd58a15bb9 by Vinay Sajip in branch 'default':
Closes #19902: Merged update from 3.3.
http://hg.python.org/cpython/rev/45bd58a15bb9

----------
nosy: +python-dev
resolution: invalid -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Dec 19 16:08:07 2013
From: report at bugs.python.org (gudge)
Date: Thu, 19 Dec 2013 15:08:07 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387465687.07.0.174588845039.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

1) Can I get a list of failures. The summary of test results which I compare on my machine.

2) 

-----------------------------------------------------------------------------------------------------
>>> import ssl
>>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")
1178649000.0
>>> from datetime import datetime
>>> datetime.utcfromtimestamp(1178668800)
datetime.datetime(2007, 5, 9, 0, 0)
>>> import time
>>> time.gmtime(1178668800)
time.struct_time(tm_year=2007, tm_mon=5, tm_mday=9, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=2, tm_yday=129, tm_isdst=0)
>>> import calender
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'calender'
>>> import callendar
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'callendar'
>>> import calendar
>>> calendar.timegm(time.strptime("May 9 00:00:00 2007 GMT", "%b %d %H:%M:%S %Y GMT"))
1178668800
----------------------------------------------------------------------------------------------------

I am running a VM on windows host machine.
In your comment ou have specified:

>>> import ssl
    >>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")
    1178694000.0

It should be `1178668800`:

But I get also get the same answer with the Python build from latest sources?
Therefore I do not get you?

3)
    3 tests omitted:
        test___all__ test_site test_urllib2net
    348 tests OK.
    3 tests failed:
        test_codecs test_distutils test_ioctl
    2 tests altered the execution environment:
        test___all__ test_site
    33 tests skipped:
        test_bz2 test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
        test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu
        test_dbm_ndbm test_devpoll test_gzip test_idle test_kqueue
        test_lzma test_msilib test_ossaudiodev test_readline test_smtpnet
        test_socketserver test_sqlite test_ssl test_startfile test_tcl
        test_timeout test_tk test_ttk_guionly test_ttk_textonly
        test_urllibnet test_winreg test_winsound test_xmlrpc_net
        test_zipfile64 test_zlib


Are these results fine. These results are with no changes. 
How can I make all tests (skipped and omiited pass)

What about the 3 tests which failed. Are these known failures?

4) 

 Now say I have to pull time again to get the latest code. Does it help
to do a make. Or I will have o do configure again.

5) I had posted a query on core-metorship? No answers? Not that I am entitled to.

Thanks

----------

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

From report at bugs.python.org  Thu Dec 19 16:20:31 2013
From: report at bugs.python.org (gudge)
Date: Thu, 19 Dec 2013 15:20:31 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387466431.04.0.905113029328.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

Sorry I think I did not read msg205774 (1st comment) correctly.
It clearly says:

"cert_time_to_seconds() uses `time.mktime()` [1] to convert utc time tuple to seconds since epoch. `mktime()` works with local time. It should use `calendar.timegm()` analog instead."

So the function cert_time_to_seconds() has to be fixed?

Thanks

----------

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

From report at bugs.python.org  Thu Dec 19 16:23:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Dec 2013 15:23:42 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387466622.03.0.613871744078.issue19940@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> So the function cert_time_to_seconds() has to be fixed?

Yes!

----------

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

From report at bugs.python.org  Thu Dec 19 19:38:13 2013
From: report at bugs.python.org (gudge)
Date: Thu, 19 Dec 2013 18:38:13 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387478292.99.0.452020806799.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

Patch is uploaded.
I will also copy paste it.

I have created the patch with git. Let me know if it is okay with you.
 If it is unacceptable I will try and create one for mercury

Patch:
------------------------------------------------------------------
diff --combined Doc/library/ssl.rst
index a6ce5d6,30cb732..0000000
--- a/Doc/library/ssl.rst
+++ b/Doc/library/ssl.rst
@@@ -366,7 -366,7 +366,7 @@@ Certificate handlin
  
       >>> import ssl
       >>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")
 -     1178694000.0
 +     1178668800 
       >>> import time
       >>> time.ctime(ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT"))
       'Wed May  9 00:00:00 2007'
diff --combined Lib/ssl.py
index f81ef91,052a118..0000000
--- a/Lib/ssl.py
+++ b/Lib/ssl.py
@@@ -852,8 -852,7 +852,8 @@@ def cert_time_to_seconds(cert_time)
      a Python time value in seconds past the epoch."""
  
      import time
 -    return time.mktime(time.strptime(cert_time, "%b %d %H:%M:%S %Y GMT"))
 +    import calendar 
 +    return calendar.timegm(time.strptime(cert_time, "%b %d %H:%M:%S %Y GMT"))
  
  PEM_HEADER = "-----BEGIN CERTIFICATE-----"
  PEM_FOOTER = "-----END CERTIFICATE-----"

-----------------------------------------------------------------

Test Results:
358 tests OK.
1 test failed:
    test_compileall
1 test altered the execution environment:
    test___all__
28 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu
    test_dbm_ndbm test_devpoll test_idle test_kqueue test_lzma
    test_msilib test_ossaudiodev test_smtpnet test_socketserver
    test_sqlite test_startfile test_tcl test_timeout test_tk
    test_ttk_guionly test_ttk_textonly test_urllibnet test_winreg
    test_winsound test_xmlrpc_net test_zipfile64
------------------------------------------------------------------------

Doc changes won't effect the code. The tests would not fail. 
How would I check if the doc changes are coming up fine in the 
final version.

>>> import ssl
>>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")
1178668800


I do not have a printer curretly. I will sign the license agreement 
in a few days.

----------
Added file: http://bugs.python.org/file33217/patch.txt

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

From report at bugs.python.org  Thu Dec 19 19:59:41 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 18:59:41 +0000
Subject: [docs] [issue18576] Rename and document test.script_helper
	as	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1387479581.35.0.102058923919.issue18576@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Thu Dec 19 20:33:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Dec 2013 19:33:29 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1387478292.99.0.452020806799.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387481605.2306.4.camel@fsol>


Antoine Pitrou added the comment:

Answering to your questions:

> I have created the patch with git. Let me know if it is okay with you.

Yes, it's ok.
Also, please don't copy / paste it. Uploading is enough.

> Doc changes won't effect the code. The tests would not fail. 
> How would I check if the doc changes are coming up fine in the 
> final version.

The devguide has detailed documentation about how to modify and build
the documentation :)
http://docs.python.org/devguide/documenting.html#building-the-documentation

As for the tests:

1. for this issue you should probably concentrate on test_ssl: to run it
in verbose mode, "./python -m test -v test_ssl"
(please read http://docs.python.org/devguide/runtests.html)

2. you will need to add a new test to test_ssl, to check that this bug
is indeed fixed

----------

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

From report at bugs.python.org  Fri Dec 20 07:48:26 2013
From: report at bugs.python.org (akira)
Date: Fri, 20 Dec 2013 06:48:26 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387522106.54.0.692172628848.issue19940@psf.upfronthosting.co.za>


akira added the comment:

gudge, have you seen http://bugs.python.org/msg205860 (the locale issue)?

If you can't fix it; say so, I'll open another issue after this issue is fixed.

----------

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

From report at bugs.python.org  Fri Dec 20 10:02:25 2013
From: report at bugs.python.org (Arnaut Billings)
Date: Fri, 20 Dec 2013 09:02:25 +0000
Subject: [docs] [issue20030] unittest.TestLoader.discover return value
	incorrectly	documented.
Message-ID: <1387530145.58.0.951879545916.issue20030@psf.upfronthosting.co.za>


New submission from Arnaut Billings:

Here: http://docs.python.org/3/library/unittest.html#unittest.TestLoader.discover

it states that "Find and return all test modules ..."

This implies that in order to get a test suite, one has to iterate over the return value of unittest.TestLoader.discover and call loadTestsFromModule for each module.

But, the type of the result of unittest.TestLoader.discover returns: <class 'unittest.suite.TestSuite'>

----------
assignee: docs at python
components: Documentation
messages: 206670
nosy: arnaut-billings, docs at python
priority: normal
severity: normal
status: open
title: unittest.TestLoader.discover return value incorrectly documented.
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec 20 10:08:19 2013
From: report at bugs.python.org (Arnaut Billings)
Date: Fri, 20 Dec 2013 09:08:19 +0000
Subject: [docs] [issue20031] unittest.TextTestRunner missing run()
	documentation.
Message-ID: <1387530499.44.0.66291527317.issue20031@psf.upfronthosting.co.za>


New submission from Arnaut Billings:

Here: http://docs.python.org/3/library/unittest.html

1) unittest.TextTestRunner is missing documentation for its public run method.

2) There are references to the TestRunner class sprinkled through out the above page, yet no link or documentation as to what that class actually is and does.

----------
assignee: docs at python
components: Documentation
messages: 206671
nosy: arnaut-billings, docs at python
priority: normal
severity: normal
status: open
title: unittest.TextTestRunner missing run() documentation.
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec 20 10:23:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 Dec 2013 09:23:58 +0000
Subject: [docs] [issue20031] unittest.TextTestRunner missing run()
	documentation.
In-Reply-To: <1387530499.44.0.66291527317.issue20031@psf.upfronthosting.co.za>
Message-ID: <1387531438.07.0.771293841299.issue20031@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti, michael.foord
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Fri Dec 20 10:24:21 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 Dec 2013 09:24:21 +0000
Subject: [docs] [issue20030] unittest.TestLoader.discover return value
	incorrectly	documented.
In-Reply-To: <1387530145.58.0.951879545916.issue20030@psf.upfronthosting.co.za>
Message-ID: <1387531461.83.0.665740815684.issue20030@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +ezio.melotti, michael.foord
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Fri Dec 20 10:24:32 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 Dec 2013 09:24:32 +0000
Subject: [docs] [issue20031] unittest.TextTestRunner missing run()
	documentation.
In-Reply-To: <1387530499.44.0.66291527317.issue20031@psf.upfronthosting.co.za>
Message-ID: <1387531472.07.0.140106487035.issue20031@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec 21 00:33:54 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2013 23:33:54 +0000
Subject: [docs] [issue20003] Language Ref "raise" doc misssing "from None"
In-Reply-To: <1387252072.89.0.572943909834.issue20003@psf.upfronthosting.co.za>
Message-ID: <1387582434.64.0.475457875642.issue20003@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Document 'from None' in raise statement doc.
type:  -> enhancement

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

From report at bugs.python.org  Sat Dec 21 11:40:25 2013
From: report at bugs.python.org (Arnaut Billings)
Date: Sat, 21 Dec 2013 10:40:25 +0000
Subject: [docs] [issue20039] Missing documentation for
	argparse.ArgumentTypeError
Message-ID: <1387622425.21.0.562750433804.issue20039@psf.upfronthosting.co.za>


New submission from Arnaut Billings:

There is no documentation for argparse.ArgumentTypeError:

http://docs.python.org/3/library/unittest.html

Though it does appear in an example and its usage is simple enough to decipher what it means, it would none the less look more professional if there was formal documentation for it. Not only on what it is, but when it should actually be used, etc...

----------
assignee: docs at python
components: Documentation
messages: 206723
nosy: arnaut-billings, docs at python
priority: normal
severity: normal
status: open
title: Missing documentation for argparse.ArgumentTypeError
versions: Python 3.3

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

From report at bugs.python.org  Sat Dec 21 15:00:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 14:00:36 +0000
Subject: [docs] [issue19861] Update What's New for Python 3.4
In-Reply-To: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>
Message-ID: <1387634436.38.0.520466327048.issue19861@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec 21 15:25:00 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 14:25:00 +0000
Subject: [docs] [issue19861] Update What's New for Python 3.4
In-Reply-To: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>
Message-ID: <1387635900.1.0.783670963825.issue19861@psf.upfronthosting.co.za>


STINNER Victor added the comment:

There is a command to generate a list a list versionchanged, but I don't remember it.

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

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

From report at bugs.python.org  Sat Dec 21 16:56:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Dec 2013 15:56:59 +0000
Subject: [docs] [issue19861] Update What's New for Python 3.4
In-Reply-To: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>
Message-ID: <1387641419.01.0.210076030134.issue19861@psf.upfronthosting.co.za>


R. David Murray added the comment:

The command is listed in 'make help'.

It was seeing this issue go by that reminded me that this job needed to be done, but it's a big one and will probably take me until the actual release to finish it, assuming I manage to finish.  (The 3.3 What's New was never finished, but I started contributing to that rather late in the game.)

----------

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

From report at bugs.python.org  Sat Dec 21 19:37:45 2013
From: report at bugs.python.org (paul j3)
Date: Sat, 21 Dec 2013 18:37:45 +0000
Subject: [docs] [issue20039] Missing documentation for
	argparse.ArgumentTypeError
In-Reply-To: <1387622425.21.0.562750433804.issue20039@psf.upfronthosting.co.za>
Message-ID: <1387651064.98.0.804345628122.issue20039@psf.upfronthosting.co.za>


paul j3 added the comment:

In argparse.py the status of ArgumentTypeError is ambiguous.

ArgumentError is listed as a public class, ArgumentTypeError is not.  It also says 'All other classes in this module are considered implementation details.'

ArgumentTypeError is a subclass of Exception (with no added functionality).

ArgumentTypeError is raised only once, in the FileType class (which is both a scripting convenience and example of a custom type).  As you note it is also used in the documentation example.  There is also one such example in test_argparse.py.

It is caught once, where it is converted into an ArgumentError.  It is handled much like a ValueError or TypeError - except that its message is passed through unchanged.  

In http://bugs.python.org/issue13824 I use it several times in the FileContext class for just this reason.  

In fact ArgumentTypeError could be documented as a footnote to the `type` block, saying to the effect: 'An ArgumentTypeError may be raised (instead of a ValueError or TypeError) to produce a custom error message.'

Normally an ArgumentTypeError is not passed back to the user code, consistent with the claim that it is not public.

--------------

Along the same line, should ArgumentError be documented better?  Currently it is just mentioned at the end, as a replacement for an optparse error class.

As best I can tell, the user code will only see an ArgumentError if the ArgumentParser.error method is customized.  Otherwise that error is caught and converted into a system exit.  Maybe the `error` paragraph in the documentation should get a sentence about ArgumentError.

In test_argparse.py, ArgumentError is used extensively (with a custom error method).

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

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

From report at bugs.python.org  Sat Dec 21 21:38:05 2013
From: report at bugs.python.org (Elias Zamaria)
Date: Sat, 21 Dec 2013 20:38:05 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1387658285.6.0.917376695995.issue19980@psf.upfronthosting.co.za>


Elias Zamaria added the comment:

I have created a patch that fixes this issue that terry.reedy described. It does not fix the problem described BreamoreBoy involving the empty string.

Please note that this is my first patch for Python so let me know if I am missing something or if I can do anything else to help.

----------
keywords: +patch
nosy: +mikez302
Added file: http://bugs.python.org/file33251/help-response.patch

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

From report at bugs.python.org  Sat Dec 21 22:23:43 2013
From: report at bugs.python.org (Arnaut Billings)
Date: Sat, 21 Dec 2013 21:23:43 +0000
Subject: [docs] [issue20039] Missing documentation for
	argparse.ArgumentTypeError
In-Reply-To: <1387622425.21.0.562750433804.issue20039@psf.upfronthosting.co.za>
Message-ID: <1387661023.33.0.575321887187.issue20039@psf.upfronthosting.co.za>


Arnaut Billings added the comment:

It seems what you're saying is that the ArgumentTypeError class should not be public, but being able to raise is should be public. If that's the case, I think it would be more clear to have an argparse.raiseArgumentTypeError method and document when it should be used.

If such classes are meant to be private, why not prepend their names with an underscore and remove them from the __all__ list? (I thought a leading underscore meant that a module level variable was private to that module.)

----------

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

From report at bugs.python.org  Sun Dec 22 01:58:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Dec 2013 00:58:00 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <3dn5054JTpz7Ljv@mail.python.org>


Roundup Robot added the comment:

New changeset 39ea24aaf0e7 by Antoine Pitrou in branch '2.7':
s/lightweight/minimal/, as per issue #11379.
http://hg.python.org/cpython/rev/39ea24aaf0e7

New changeset b63258b6eb4d by Antoine Pitrou in branch '3.3':
s/lightweight/minimal/, as per issue #11379.
http://hg.python.org/cpython/rev/b63258b6eb4d

New changeset d659e7761d59 by Antoine Pitrou in branch 'default':
s/lightweight/minimal/, as per issue #11379.
http://hg.python.org/cpython/rev/d659e7761d59

----------

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

From report at bugs.python.org  Sun Dec 22 01:58:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 00:58:11 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1387673890.94.0.59491400377.issue17538@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Dec 22 08:31:40 2013
From: report at bugs.python.org (gudge)
Date: Sun, 22 Dec 2013 07:31:40 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387697499.95.0.343908675675.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

Akira, I will fix it. I will put in the patch in the same bug.

----------

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

From report at bugs.python.org  Sun Dec 22 18:48:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 17:48:59 +0000
Subject: [docs] [issue19508] Add warning that Python doesn't verify SSL
	certs by	default
In-Reply-To: <1383691927.99.0.022250098505.issue19508@psf.upfronthosting.co.za>
Message-ID: <1387734539.69.0.166326548003.issue19508@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

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

From report at bugs.python.org  Sun Dec 22 19:05:11 2013
From: report at bugs.python.org (gudge)
Date: Sun, 22 Dec 2013 18:05:11 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387735511.54.0.40374298601.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

1) I understand I can run a whole test suite as
./python -m test -v test_abc
as mentioned in
http://docs.python.org/devguide/runtests.html

How do I run a particluar test case, like the test I added
test_cert_time_to_seconds

2) I have a added a test case test_cert_time_to_seconds to test_ssl.py. 
3) ./python -m test -v test_ssl
   is all PASS.

4) I will start my work on http://bugs.python.org/issue19940#msg205860.

5) The patch is attached.

----------
Added file: http://bugs.python.org/file33254/patch.txt

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

From report at bugs.python.org  Mon Dec 23 09:55:54 2013
From: report at bugs.python.org (yegle)
Date: Mon, 23 Dec 2013 08:55:54 +0000
Subject: [docs] [issue19861] Update What's New for Python 3.4
In-Reply-To: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>
Message-ID: <1387788954.67.0.278482817924.issue19861@psf.upfronthosting.co.za>


yegle added the comment:

Hi all,

It's my first time commenting on this issue tracker so bear with me if this looks naive.

For the `plistlib` package, from Apple's own manual[1], there's actually a third JSON format.

It'll be good to indicate that `plistlib` doesn't support JSON format in the what's new page and corresponding document page.

It takes me sometime before I realize `plistlib` in Python 3.3 doesn't support the so called binary property list format. So if the JSON format won't be supported in this Python version, it'll save someone's time by just reading the manual.

[1]: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/plutil.1.html

----------
nosy: +yegle

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

From report at bugs.python.org  Mon Dec 23 10:53:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Dec 2013 09:53:20 +0000
Subject: [docs] [issue19861] Update What's New for Python 3.4
In-Reply-To: <1387788954.67.0.278482817924.issue19861@psf.upfronthosting.co.za>
Message-ID: <3857539.FP5nrOTbfM@raxxla>


Serhiy Storchaka added the comment:

> For the `plistlib` package, from Apple's own 
manual[1], there's actually a
> third JSON format.

See *issue14455.*

----------

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

From report at bugs.python.org  Mon Dec 23 15:53:03 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Dec 2013 14:53:03 +0000
Subject: [docs] [issue19861] Update What's New for Python 3.4
In-Reply-To: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>
Message-ID: <1387810383.7.0.409603439821.issue19861@psf.upfronthosting.co.za>


R. David Murray added the comment:

Unless I missed something, the changes to plistlib didn't make the Beta cutoff for 3.4, so there's nothing to be done for whatsnew with regard to it.  If the current documentation needs clarification, please open a new issue for that topic.

----------

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

From report at bugs.python.org  Mon Dec 23 15:57:27 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Dec 2013 14:57:27 +0000
Subject: [docs] [issue19861] Update What's New for Python 3.4
In-Reply-To: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>
Message-ID: <1387810647.73.0.769182590037.issue19861@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, looks like I did miss something.  I'll have to sort out what actually changed, since issue 14455 is still open.  I'll have to think about whether or not it is appropriate to discuss something that *hasn't* been added yet in whatsnew...

----------

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

From report at bugs.python.org  Tue Dec 24 16:33:15 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 24 Dec 2013 15:33:15 +0000
Subject: [docs] [issue20063] Docs imply that set does not support .pop()
	method
Message-ID: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>


New submission from Madison May:

Note item 6 of http://docs.python.org/2.7/library/stdtypes.html#mutable-sequence-types is a bit misleading.  

It states: "The pop() method is only supported by the list and array types. The optional argument i defaults to -1, so that by default the last item is removed and returned."  

However, pop() is also a method of sets, which are neither lists or arrays.

----------
assignee: docs at python
components: Documentation
messages: 206899
nosy: docs at python, madison.may
priority: normal
severity: normal
status: open
title: Docs imply that set does not support .pop() method
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec 24 17:12:04 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 16:12:04 +0000
Subject: [docs] [issue20063] Docs imply that set does not support .pop()
	method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <1387901524.7.0.944735935518.issue20063@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, set supporting it is irrelevant to that section, which is about mutable sequence types.  However, bytearray also supports pop, so I think perhaps that sentence should just be deleted.  The whole footnote is gone in the Python3. docs.

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

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

From report at bugs.python.org  Tue Dec 24 17:18:43 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 24 Dec 2013 16:18:43 +0000
Subject: [docs] [issue20063] Docs imply that set does not support .pop()
	method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <1387901923.3.0.579391964762.issue20063@psf.upfronthosting.co.za>


Madison May added the comment:

+1 for simply deleting that bit

----------

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

From report at bugs.python.org  Tue Dec 24 18:37:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Dec 2013 17:37:51 +0000
Subject: [docs] [issue18529] Use long dash
In-Reply-To: <1374499433.16.0.583158051605.issue18529@psf.upfronthosting.co.za>
Message-ID: <3dpl4t1LNlz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 01d2c25a6804 by R David Murray in branch 'default':
Use endash in PEP callouts.
http://hg.python.org/cpython/rev/01d2c25a6804

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

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

From report at bugs.python.org  Tue Dec 24 20:39:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 19:39:20 +0000
Subject: [docs] [issue20064] PyObject_Malloc is not documented
Message-ID: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>


New submission from R. David Murray:

At least, a doc ref to :c:func:`PyObject_Malloc` does not turn into a link, and I can't find anything in the docs that it looks like it should link to.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 206910
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: PyObject_Malloc is not documented
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec 24 20:45:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Dec 2013 19:45:59 +0000
Subject: [docs] [issue18688] Document undocumented Unicode object API
In-Reply-To: <1375989166.23.0.200448183394.issue18688@psf.upfronthosting.co.za>
Message-ID: <1387914359.45.0.0617820879691.issue18688@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Dec 25 02:12:16 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Wed, 25 Dec 2013 01:12:16 +0000
Subject: [docs] [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1387933936.3.0.361574436842.issue20064@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

Hi, 

I created the patch, please kindly review it, all comments are welcomed.

Thank you!

----------
keywords: +patch
nosy: +gennad
Added file: http://bugs.python.org/file33261/20064.patch

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

From report at bugs.python.org  Wed Dec 25 02:41:41 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Wed, 25 Dec 2013 01:41:41 +0000
Subject: [docs] [issue20063] Docs imply that set does not support .pop()
	method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <1387935701.21.0.307988561595.issue20063@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

Here's the patch

----------
keywords: +patch
nosy: +gennad
Added file: http://bugs.python.org/file33262/20063.patch

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

From report at bugs.python.org  Wed Dec 25 03:48:00 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Dec 2013 02:48:00 +0000
Subject: [docs] [issue20063] Docs imply that set does not support .pop()
	method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <1387939680.18.0.297864461077.issue20063@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, but the proposal for 2.7 is to just delete the sentence about list/array, not the whole footnote.  Unless someone can think of a mutable list type in 2.7 that does not support pop...

----------

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

From report at bugs.python.org  Wed Dec 25 04:26:56 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Wed, 25 Dec 2013 03:26:56 +0000
Subject: [docs] [issue20063] Docs imply that set does not support .pop()
	method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <1387942016.02.0.999823664119.issue20063@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

Got it. Looks like I was confused by absence of this footnote in Python 3 documentation) Here's updated patch.

----------
Added file: http://bugs.python.org/file33263/20063.patch

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

From report at bugs.python.org  Wed Dec 25 21:45:05 2013
From: report at bugs.python.org (Julian Gindi)
Date: Wed, 25 Dec 2013 20:45:05 +0000
Subject: [docs] [issue18566] In unittest.TestCase docs for setUp() and
	tearDown()	don't mention AssertionError
In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za>
Message-ID: <1388004305.57.0.105695168087.issue18566@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Looks like this issue has been resolved. Can we close it?

----------

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

From report at bugs.python.org  Wed Dec 25 22:16:38 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 Dec 2013 21:16:38 +0000
Subject: [docs] [issue18566] In unittest.TestCase docs for setUp() and
	tearDown()	don't mention AssertionError
In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za>
Message-ID: <1388006198.82.0.142638290119.issue18566@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Resolved in what way? The doc seems unchanged.

----------

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

From report at bugs.python.org  Wed Dec 25 22:23:52 2013
From: report at bugs.python.org (Julian Gindi)
Date: Wed, 25 Dec 2013 21:23:52 +0000
Subject: [docs] [issue18566] In unittest.TestCase docs for setUp() and
	tearDown()	don't mention AssertionError
In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za>
Message-ID: <1388006632.32.0.795800474465.issue18566@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Sorry. I meant, merged.

----------

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

From report at bugs.python.org  Wed Dec 25 22:39:42 2013
From: report at bugs.python.org (py.user)
Date: Wed, 25 Dec 2013 21:39:42 +0000
Subject: [docs] [issue18566] In unittest.TestCase docs for setUp() and
	tearDown()	don't mention AssertionError
In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za>
Message-ID: <1388007582.67.0.384215173191.issue18566@psf.upfronthosting.co.za>


py.user added the comment:

I have built 3.4.0a4 and run - same thing

----------

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

From report at bugs.python.org  Thu Dec 26 04:27:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Dec 2013 03:27:15 +0000
Subject: [docs] [issue20063] Docs imply that set does not support .pop()
	method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <3dqc6V3tV1z7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 3598805d7636 by R David Murray in branch '2.7':
#20063: Remove inaccurate/confusing statement about support of 'pop' method.
http://hg.python.org/cpython/rev/3598805d7636

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

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

From report at bugs.python.org  Thu Dec 26 04:27:57 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Dec 2013 03:27:57 +0000
Subject: [docs] [issue20063] Docs imply that set does not support .pop()
	method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <1388028477.35.0.514348897474.issue20063@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Gennandiy.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Thu Dec 26 07:42:48 2013
From: report at bugs.python.org (Julian Gindi)
Date: Thu, 26 Dec 2013 06:42:48 +0000
Subject: [docs] [issue20068] collections.Counter documentation leaves out
	interesting	usecase
Message-ID: <1388040167.94.0.902280065341.issue20068@psf.upfronthosting.co.za>


New submission from Julian Gindi:

I think the documentation for collections.Counter can be updated slightly to include an example showing the initialization of a counter object from a list. For example, it explains how to manually iterate through a list and increment the values...

for word in ['red', 'blue', 'red', 'green', 'blue', 'blue']:
...     cnt[word] += 1

I think it is more useful and powerful to do something like this:

cnt = Counter(['red', 'blue', 'red', 'green', 'blue', 'blue'])

where the result would be:

Counter({'blue': 3, 'red': 2, 'green': 1})

Just a thought. I'm curious to see what other people think.

----------
assignee: docs at python
components: Documentation
messages: 206935
nosy: Julian.Gindi, docs at python, rhettinger
priority: normal
severity: normal
status: open
title: collections.Counter documentation leaves out interesting usecase
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Dec 28 16:14:34 2013
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 28 Dec 2013 15:14:34 +0000
Subject: [docs] [issue20090] slight ambiguity in README.txt instructions for
	building	docs
Message-ID: <1388243674.59.0.297728620179.issue20090@psf.upfronthosting.co.za>


New submission from Mitchell Model:

I tried to build the docs for v3.4.0b1 following the instructions in the Doc/README.txt. My default python is v3.3. I got the following error message:
"Error: Sphinx needs to be executed with Python 2.4 or newer (not 3.0 though)."
I wondered what was weird about 3.0 as opposed to later versions that it wouldn't work. Fortunately I had run into other situations where tools expected Python 2 but wouldn't work with Python 3, so after a few minutes of head scratching I tried using Python 2, whi

Sphinx needs to be executed with Python 2 (v. 2.4 or newer), not Python 3

 so that it makes clear that it requires Python 2 not Python 3 and puts the grammatical emphasis where it belongs.

More importantly, perhaps, the Doc README should be changed to state that make must use Python 2.

----------
assignee: docs at python
components: Build, Documentation
messages: 207029
nosy: MLModel, docs at python
priority: normal
severity: normal
status: open
title: slight ambiguity in README.txt instructions for building docs
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec 28 16:17:22 2013
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 28 Dec 2013 15:17:22 +0000
Subject: [docs] [issue20091] An index entery for __main__ in "30.5 runpy" is
	missing
Message-ID: <1388243842.91.0.578293707742.issue20091@psf.upfronthosting.co.za>


New submission from Mitchell Model:

An index entry should be added for __main__ as it appears in the documentation of runpy (30.5 in 3.3, 31.5 in 3.4).

----------
assignee: docs at python
components: Documentation
messages: 207030
nosy: MLModel, docs at python
priority: normal
severity: normal
status: open
title: An index entery for __main__ in "30.5 runpy" is missing
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Dec 28 16:45:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Dec 2013 15:45:30 +0000
Subject: [docs] [issue20091] An index entry for __main__ in "30.5 runpy" is
	missing
In-Reply-To: <1388243842.91.0.578293707742.issue20091@psf.upfronthosting.co.za>
Message-ID: <1388245530.04.0.945860840262.issue20091@psf.upfronthosting.co.za>


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


----------
title: An index entery for __main__ in "30.5 runpy" is missing -> An index entry for __main__ in "30.5 runpy" is missing

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

From report at bugs.python.org  Sun Dec 29 08:54:34 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 29 Dec 2013 07:54:34 +0000
Subject: [docs] [issue20090] slight ambiguity in README.txt instructions for
	building	docs
In-Reply-To: <1388243674.59.0.297728620179.issue20090@psf.upfronthosting.co.za>
Message-ID: <1388303674.07.0.26179856716.issue20090@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Dec 29 16:56:08 2013
From: report at bugs.python.org (Mike Short)
Date: Sun, 29 Dec 2013 15:56:08 +0000
Subject: [docs] [issue19890] Typo in multiprocessing docs
In-Reply-To: <1386198252.12.0.881873603907.issue19890@psf.upfronthosting.co.za>
Message-ID: <1388332568.22.0.251678875709.issue19890@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file33287/multiprocessing.patch

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

From report at bugs.python.org  Sun Dec 29 16:58:34 2013
From: report at bugs.python.org (Mike Short)
Date: Sun, 29 Dec 2013 15:58:34 +0000
Subject: [docs] [issue19890] Typo in multiprocessing docs
In-Reply-To: <1386198252.12.0.881873603907.issue19890@psf.upfronthosting.co.za>
Message-ID: <1388332714.26.0.0554503868378.issue19890@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


----------
nosy: +Mike.Short

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

From report at bugs.python.org  Sun Dec 29 19:29:54 2013
From: report at bugs.python.org (gudge)
Date: Sun, 29 Dec 2013 18:29:54 +0000
Subject: [docs] [issue19940] ssl.cert_time_to_seconds() returns wrong
	results if	local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1388341794.11.0.831553684383.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

Can you please provide some hints on how to handle
http://bugs.python.org/issue19940#msg205860.

The value of format_regex

1) Without locale set:
re.compile('(?P<b>jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)\\s+(?P<d>3[0-1]|[1-2]\\d|0[1-    9]|[1-9]| [1-9])\\s+(?P<H>2[0-3]|[0-1]\\d|\\d):(?P<M>[0-5]\\d|\\d):(?P<S>6[0-1]|[0-5]\\d|\\d)\\s    +(?P<Y>\\d\\d\\d\\d, re.IGNORECASE)

2) With locale set:
re.compile('(?P<b>sty|lut|mar|kwi|maj|cze|lip|sie|wrz|pa\\?|lis|gru)\\s+(?P<d>3[0-1]|[1-2]\\d|0[    1-9]|[1-9]| [1-9])\\s+(?P<H>2[0-3]|[0-1]\\d|\\d):(?P<M>[0-5]\\d|\\d):(?P<S>6[0-1]|[0-5]\\d|\\d)\    \s+(?P<Y>\\d\\d\\d\, re.IGNORECASE)

The value of months are different.

Thanks

----------

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

From report at bugs.python.org  Mon Dec 30 00:39:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Dec 2013 23:39:07 +0000
Subject: [docs] [issue20031] unittest.TextTestRunner missing run()
	documentation.
In-Reply-To: <1387530499.44.0.66291527317.issue20031@psf.upfronthosting.co.za>
Message-ID: <3dsysQ41y2z7Ljm@mail.python.org>


Roundup Robot added the comment:

New changeset 19464d77ec2e by Michael Foord in branch 'default':
Closes issue 20031. Document unittest.TextTestRunner.run method.
http://hg.python.org/cpython/rev/19464d77ec2e

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Dec 30 00:54:33 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 29 Dec 2013 23:54:33 +0000
Subject: [docs] [issue18566] In unittest.TestCase docs for setUp() and
	tearDown()	don't mention AssertionError
In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za>
Message-ID: <1388361273.4.0.126431242357.issue18566@psf.upfronthosting.co.za>


Michael Foord added the comment:

Yep, those docs are just wrong. I'm trying to think of a concise rewording.

----------

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

From report at bugs.python.org  Mon Dec 30 20:43:50 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Dec 2013 19:43:50 +0000
Subject: [docs] [issue20096] Mention modernize and future in Python 2/3
	porting HOWTO
Message-ID: <1388432630.2.0.0690952057164.issue20096@psf.upfronthosting.co.za>


New submission from Brett Cannon:

https://github.com/mitsuhiko/python-modernize
http://python-future.org/

Should also restructure to de-emphasize 2to3 and other approaches. In all honesty it should probably be nearly gutted to just "here are examples of how to write Python 2/3 compatible code", point to appropriate libraries, and be done with it with a minimal mention of 2to3 and 3to2.

----------
assignee: docs at python
components: Documentation
messages: 207103
nosy: brett.cannon, docs at python
priority: normal
severity: normal
status: open
title: Mention modernize and future in Python 2/3 porting HOWTO
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 30 20:55:00 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 30 Dec 2013 19:55:00 +0000
Subject: [docs] [issue20096] Mention modernize and future in Python 2/3
	porting HOWTO
In-Reply-To: <1388432630.2.0.0690952057164.issue20096@psf.upfronthosting.co.za>
Message-ID: <1388433300.49.0.698838749481.issue20096@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/issue20096>
_______________________________________

From report at bugs.python.org  Tue Dec 31 16:58:14 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 Dec 2013 15:58:14 +0000
Subject: [docs] [issue20100] epoll docs are not clear with regards to
	CLOEXEC.
Message-ID: <1388505494.08.0.643576998185.issue20100@psf.upfronthosting.co.za>


New submission from R. David Murray:

http://docs.python.org/dev/library/select.html#select.epoll documents the EPOLL_CLOEXEC flag as something you can specify that makes the file descriptor be closed on exec.  But then it goes on to say that the file descriptor is non-inheritable.  So is the flag useless and should be removed from the docs, or is the documentation just unclear as to its purpose?  Or, conversely, do we need a way to say that the file descriptor should *not* be closed on exec?

----------
assignee: docs at python
components: Documentation
messages: 207121
nosy: docs at python, haypo, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: epoll docs are not clear with regards to CLOEXEC.
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec 31 17:20:00 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Dec 2013 16:20:00 +0000
Subject: [docs] [issue20100] epoll docs are not clear with regards to
	CLOEXEC.
In-Reply-To: <1388505494.08.0.643576998185.issue20100@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ1O1uUuXWEpZhxZuePBDuz-Cez-ZNPxKjGL-3nk_yU7w@mail.gmail.com>


STINNER Victor added the comment:

Use os.set_inheritable(epoll.fileno(), True) to make the file descriptor
inheritable. You should find this info easily if you follow the link on
"non inheritable" in epoll documentation.

EPOLL_CLOEXEC becomes useless in Python 3.4. It is used internally by
default if available. Removing it would break existing code, it would be
harder to write code for python 3.4 and 3.3.

Just update the doc.

----------

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

From report at bugs.python.org  Tue Dec 31 23:09:03 2013
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Dec 2013 22:09:03 +0000
Subject: [docs] [issue20096] Mention modernize and future in Python 2/3
	porting HOWTO
In-Reply-To: <1388432630.2.0.0690952057164.issue20096@psf.upfronthosting.co.za>
Message-ID: <1388527743.41.0.328424037148.issue20096@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/issue20096>
_______________________________________

From ruyasan at gmail.com  Thu Dec 19 00:25:41 2013
From: ruyasan at gmail.com (Ruy Asan)
Date: Wed, 18 Dec 2013 23:25:41 -0000
Subject: [docs] Descriptor HowTo Guide: 2 bits of misleading information
Message-ID: <CACQ-8Czxmv8keOBSn0v4BY932qzREif7_E4vGPN_6V0wrp7oLA@mail.gmail.com>

They gave me a bit of a headache until I figured out it was the guide
itself that was the problem...

Issues appear to be present in all versions up to the current dev branch
(3.4): http://docs.python.org/3.4/howto/descriptor.html


1) Under "Descriptor
Protocol<http://docs.python.org/3.4/howto/descriptor.html#descriptor-protocol>"
the method signature for __get__ is just outright wrong:

descr.__get__(self, obj, type=None) --> value

The type argument is not optional (though obj can be None, but that's not
part of the signature at all). I also think using "obj" and "type"
needlessly inconsistent, pretty much all documentation uses "instance" and
"owner" instead (and they are arguably better descriptions to begin with).

It shouldn't be a big deal but since that is actually the very first
mention of __get__'s signature if you just google "python descriptors",
well, I for one took note of it and stopped paying attention to subsequent
examples.

2) Under "Descriptor
Example<http://docs.python.org/3.4/howto/descriptor.html#descriptor-example>"
the use of "self.value" to store instance data is just very very
misleading. Of course it works in that particular example and this being an
introductory "HowTo" should suggest that none of the examples are actually
meant for production code, but  still, it's showing off a reasonably common
application of descriptors (... storing property values) but using a
*wrong* implementation
(and "*wrong"* in a pretty not-obvious way to catch as well!). Stack
overflow questions and 3rd party guides to descriptors keep having to point
out how that's a bad example.

It also doesn't help that the right way of doing that sort of thing is not
at all trivial and full of pitfalls (internal weakref dicts don't work if
the descriptors are attached to a non-hashable class, and storing in
instance.__dict__ either relies on having to repeat yourself when assigning
descriptors (so they can shadow their own name, but they can only know
their name if explicitly told to them in __init__ or somesuch), or
polluting the instance object with ugly underscore "private values" for
each descriptor).

If storing property values is indeed a valid application of descriptors,
then ideally the HowTo guide should include an official recommended
reference implementation (clearly stating the tradeoffs). -OR-, if this is
the sort of thing that is tricky and difficult because it's *not* actually
a valid application of descriptors (or at least frowned upon) then maybe it
would be best if the HowTo guide used a different type of example
altogether.

Cheers,
- Ruy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20131218/15b1f321/attachment-0001.html>

From hellyeas at gmail.com  Thu Dec 19 17:15:10 2013
From: hellyeas at gmail.com (Elizabeth Kehler)
Date: Thu, 19 Dec 2013 16:15:10 -0000
Subject: [docs] Possible dictionary documentation improvement
Message-ID: <CADfQuR5At_OKjEWNy0pmqS8eJSP-fR4pJh9ojKy5BKz5JFoCvQ@mail.gmail.com>

Hello,

I have been trying to learn python from the documentation, and until
recently I had no idea how to use dictionaries. Until someone told me in
plain english that dictionaries are collections of entries which you use to
look up a value from a unique key of your choosing, I couldn't make heads
or tails of your documentation. Mostly what I needed to know was that an
entry had the form {key:value} and that more entries could be added by
separating by commas like {key1:value1, key2:value2} and that "=" can be
used instead of ":"

The part where your documentation addresses this is the third paragraph
down like so:

Dictionaries can be created by placing a comma-separated list of key:
value pairs
within braces, for example: {'jack': 4098, 'sjoerd': 4127} or{4098: 'jack',
4127: 'sjoerd'}, or by the
dict<http://docs.python.org/2.7/library/stdtypes.html#dict>
 constructor.

Reading your documentation now with the above knowledge it makes perfect
sense, but when I was new to it, I didn't get the information I needed. I
stongly advise rewording this documentation by adding a paragraph at the
beginning talking about how dictionaries are used in plain english, and
stating that the key comes first and the value second in each entry without
saying that you "can" do it that way. To someone new, the word "can" sounds
like you are introducing a nonstandard way of doing things that might be
interesting to someone who already knows what is going on, but not very
useful in figuring out how these things actually work.

Thanks for taking the time to read through my criticism. I really
appreciate everything you guys are doing.

-Elizabeth Kehler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20131219/af0e942e/attachment-0001.html>

From jmsachs at gmail.com  Sat Dec 21 00:16:08 2013
From: jmsachs at gmail.com (Jason Sachs)
Date: Fri, 20 Dec 2013 23:16:08 -0000
Subject: [docs] docs for collections.deque do not mention how to check
 whether the deque is empty
Message-ID: <CAOo6sOP71WiAWxZeL4OnAk58btxvsoz97F__pvFajJ2vZ3KGhQ@mail.gmail.com>

http://docs.python.org/2/library/collections.html#collections.deque

If I have a deque containing a large number of items, and I just want to
know whether the deque is empty or not, I shouldn't have to call len().
 But the documentation does not mention any way to check to see if the
deque is empty without having to count the number of items.

It appears from what I've read on the internet (incl.
http://stackoverflow.com/questions/5652278/python-2-7-how-to-check-if-a-deque-is-empty)
that there is an implicit conversion to bool which returns True if the
deque contains any items, and returns False if the deque is empty.

If this is true, could you add this to the docs for deque?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20131220/1059baf7/attachment-0001.html>

From chaplinsky.dmitry at gmail.com  Fri Dec 27 02:50:18 2013
From: chaplinsky.dmitry at gmail.com (Dmitry Chaplinsky)
Date: Fri, 27 Dec 2013 01:50:18 -0000
Subject: [docs] Typo in urllib2 docs
Message-ID: <CACekEaV-7JzUmK8_98k=NbOXnC-3--vBdAowM6Z2mPyKFhA6qw@mail.gmail.com>

http://docs.python.org/2/library/urllib2.html

This function returns a file-like object with *two* additional methods:

   - geturl() ? return the URL of the resource retrieved, commonly used to
   determine if a redirect was followed
   - info() ? return the meta-information of the page, such as headers, in
   the form of an
mimetools.Message<http://docs.python.org/2/library/mimetools.html#mimetools.Message>instance
(see Quick
   Reference to HTTP Headers <http://www.cs.tut.fi/%7Ejkorpela/http.html>)
   - getcode() ? return the HTTP status code of the response.

docs says about two methods but 3 are listed.

WBR, Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20131227/4c429863/attachment-0001.html>

From randy at thinhorn.com  Fri Dec 27 22:31:06 2013
From: randy at thinhorn.com (R. Sage)
Date: Fri, 27 Dec 2013 21:31:06 -0000
Subject: [docs] proposed improvement to 'else' explanation for
	try/except/else
Message-ID: <CAE6jqdiBUkEPhPtMOTppC0B+Bw4+2QBxkp69TO578yjBEeh5DA@mail.gmail.com>

I suggest changing the following paragraph as annotated (from
http://docs.python.org/2/tutorial/errors.html):

> The use of the else clause is better than adding additional code to the
> try clause because *the else clause is excluded from the try's
> protection.  This* [was "it"] avoids accidentally catching an exception
> that wasn?t raised by the code *that is intended to be* [was "being"]
> protected by the try ... except statement."  I suggest augmenting this
> either with more text or with an example.
>

I initially could not decipher this.

I love the docs!  Cheers,
Randy Sage

PS Original (verbose) email follows in case it is useful - but no need to
read it.  I decided  that anybody who succeeds at such concise
documentation deserves a better effort on my part.

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

First, I love the docs!  They are the main reason I'm increasingly moving
my work into Python, currently abandoning ruby/rails, but also migrating
away from MATLAB and bash scripts.

After I read the tutorial on exceptions (
http://docs.python.org/2/tutorial/errors.html), I went looking for a better
explanation of:

> The use of the else clause is better than adding additional code to the
> try clause because it avoids accidentally catching an exception that wasn?t
> raised by the code being protected by the try ... except statement."  I
> suggest augmenting this either with more text or with an example.
>

The supplementary description at
http://stackoverflow.com/a/855764/527489was perfect for me, but is
more verbose than typical python docs, which I
usuallyl find to be about as concise as possible - but no more so.

In this case, I think the issue is that the docs are too concise for those
new to the concept, albeit I now see that they are perfect if you know (at
least approximately) what that the try/except's else is for.  I'm not great
at being concise myself (sorry about the long email), but perhaps something
like this:

The use of the else clause is better than adding additional code to the try
> clause because *the else clause is excluded from the try's protection.
> This* [was "it"] avoids accidentally catching an exception that wasn?t
> raised by the code *that is intended to be* [was "being"] protected by
> the try ... except statement."  I suggest augmenting this either with more
> text or with an example.


Thanks,
Randy Sage
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20131227/0bfe5cd3/attachment-0001.html>

From camikasi at msn.com  Sat Dec 28 01:34:22 2013
From: camikasi at msn.com (Camil Kassar)
Date: Sat, 28 Dec 2013 00:34:22 -0000
Subject: [docs] Print Command
Message-ID: <SNT145-W638DBACECD28B51D7DE813D3CC0@phx.gbl>

IN Topic 2 and Topic 3, (maybe later topics) print commands are missing parenthesis, for example:
>>> i = 256*256
>>> print 'The value of i is', i
The value of i is 65536Should be>>> i = 256*256
>>> print ('The value of i is', i)
The value of i is 65536 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20131228/944bb832/attachment.html>

From jbradley5000 at gmail.com  Sat Dec 28 09:20:18 2013
From: jbradley5000 at gmail.com (Jeff Bradley)
Date: Sat, 28 Dec 2013 08:20:18 -0000
Subject: [docs] Environment Variable Documentation Clarification Needed
Message-ID: <CADcJtySmbyAKKcEjxjegGL=rk3zVX+EydJHK2kkyh6vWoYMp0A@mail.gmail.com>

On this page: http://docs.python.org/2/using/windows.html#setting-envvars

the instructions mention a pythonpath environment variable (which led me to
believe I need to create that environment variable).  I wasn't able to get
this to work.  What did work was adding the following to the end of the
existing Path variable:
;C:\Python27\;C:\Python27\Scripts\

Once I closed and reopened command prompt, windows recognized the python
command.

The path variable is mentioned here: http://docs.python.org/2/faq/windows,
however I would suggest editing the faq page to say, "Add the following to
the end of the PATH environment variable:
;C:\Python27\;C:\Python27\Scripts\".


This is the page that clarified the steps I needed to take to get the
environment variable set correctly:
http://docs.python-guide.org/en/latest/starting/install/win/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20131228/42918cc3/attachment-0001.html>

From graemehattan7 at hotmail.com  Mon Dec 30 20:08:30 2013
From: graemehattan7 at hotmail.com (Graeme Hattan)
Date: Mon, 30 Dec 2013 19:08:30 +0000
Subject: [docs] Python datetime documentation addition request
Message-ID: <DUB122-W41095D1DCE36351F4332FAE7CE0@phx.gbl>

Hello,

It would be really nice if the documentation for strftime/strptime made a mention or gave an example of how to print dates in the system locale since python does not do this by default. The documentation page is -

http://docs.python.org/2/library/datetime.html#strftime-strptime-behavior

For more information, see -

http://stackoverflow.com/questions/3438120/python-date-formatted-with-x-locale-is-not-as-expected

Thanks,

Graeme
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20131230/4642075d/attachment-0001.html>

From rrossi at cimne.upc.edu  Tue Dec 31 18:15:12 2013
From: rrossi at cimne.upc.edu (Riccardo Rossi)
Date: Tue, 31 Dec 2013 18:15:12 +0100
Subject: [docs] documentation bug in "embedding python"
Message-ID: <CAOVdALyPtnFrsmG8TyNqW69yFVYvFVSrMhca8NOx35kupMiP8Q@mail.gmail.com>

Dear developers,

i tried the simplest possible embedding described in

http://docs.python.org/3.3/extending/embedding.html#very-high-level-embedding

using python3.

the example code does not compile (from c++) with error:
/home/riccardo/scratch/kratospy3/embedded_python/krun_main.cpp: In function
?int main(int, char**)?:
/home/riccardo/scratch/kratospy3/embedded_python/krun_main.cpp:8:28: error:
cannot convert ?char*? to ?wchar_t*? for argument ?1? to ?void
Py_SetProgramName(wchar_t*)?
   Py_SetProgramName(argv[0]);  /* optional but recommended */
                            ^


what is the correct version for this?

if i define the main with wchar_t instead of char i get a warning...

thank you in advance
Riccardo

-- 

Dr. Riccardo Rossi, Civil Engineer

Member of Kratos Team

International Center for Numerical Methods in Engineering - CIMNE
Campus Norte, Edificio C1

c/ Gran Capit?n s/n

08034 Barcelona, Espa?a

Tel:        (+34) 93 401 56 96

Fax:       (+34) 93.401.6517
web:       www.cimne.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20131231/0b79acb4/attachment-0001.html>