Mailman 3 August 2017 - docs

[issue26656] Documentation for re.compile is a bit outdated
by Sworddragon Aug. 28, 2017

Aug. 28, 2017

New submission from Sworddragon: The documentation for re.compile says "Compile a regular expression pattern into a regular expression object, which can be used for matching using its match() and search() methods, described below." which implies that match() and search() are the only methods for it while there are a few more. Maybe this sentence should be worded more generic or at least complete the list. ---------- assignee: docs@python components: Documentation messages: 262571 nosy: Sworddragon, docs@python priority: normal severity: normal status: open title: Documentation for re.compile is a bit outdated type: behavior versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26656> _______________________________________

12 19

[issue31191] Fix grammar in threading.Barrier docs
by Mariatta Wijaya Aug. 27, 2017

Aug. 27, 2017

Changes by Mariatta Wijaya <mariatta.wijaya(a)gmail.com>: ---------- resolution: -> fixed stage: backport needed -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31191> _______________________________________

1 0

[issue31191] Fix grammar in threading.Barrier docs
by Mariatta Wijaya Aug. 27, 2017

Aug. 27, 2017

Mariatta Wijaya added the comment: New changeset 2dfafa3c565c0b51920269a891fa270848b378d5 by Mariatta in branch '3.6': bpo-31191: Improve grammar in threading.Barrier docs (GH-3080) (GH-3224) https://github.com/python/cpython/commit/2dfafa3c565c0b51920269a891fa270848… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31191> _______________________________________

1 0

[issue31191] Fix grammar in threading.Barrier docs
by Mariatta Wijaya Aug. 27, 2017

Aug. 27, 2017

Changes by Mariatta Wijaya <mariatta.wijaya(a)gmail.com>: ---------- pull_requests: +3266 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31191> _______________________________________

1 0

Python 2 docs download links broken
by Daz30 . Aug. 27, 2017

Aug. 27, 2017

Hi there, Just letting you know the Python2 doc links are broken, unable to download the pdf of both versions listed on the download page https://docs.python.org/2/download.html Are they listed else where? and is there a single pdf document for these docs as well? Thanks Darian

1 0

Doc page at https://docs.python.org/2.7/download.html
by Ofnuts Aug. 27, 2017

Aug. 27, 2017

All links are down (doc for 2.7.14RC1 not ready yet?). IMHO since it's a RC the version selector at the bottom right should keep a 2.7.13 entry (in fact, many people having to use ancient 2.7.x Python versions would still benefit from having easy access to old 2.7.x docs). Cheers.

1 0

Python documentation downloading on Android
by Rohit Hegde Aug. 27, 2017

Aug. 27, 2017

Sir/Mam, Recently I tried to download python 2.7.x documentation on my android device, but I am getting error 404 status. Please look into the matter. Regards Rohit.

1 0

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object
by R. David Murray Aug. 26, 2017

Aug. 26, 2017

R. David Murray added the comment: OK, agreed. The general principle is: if you reference the name, it is looked up in the the builtins namespace at runtime (effectively an indirect reference). If the syntax doesn't explicitly mention the name, then it is going to be (the equivalent of) a direct reference, and changing builtins won't change it. So this is really just a specific example of how python namespacing works in general. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31283> _______________________________________

1 0

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object
by Raymond Hettinger Aug. 26, 2017

Aug. 26, 2017

Raymond Hettinger added the comment: I agree with the other commenters and recommend this be closed. There doesn't seem to be a a useful issue here. It seems more like a pedantic twisting of words that ignores how Python works (i.e. that you can specify a specific class to inherit from and that it is possible to either shadow or alter builtins). I don't see any magic here beyond changing a variable name to refer to a new object while previous references (or builtin references) to that name continue to refer to old object. ---------- nosy: +rhettinger _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31283> _______________________________________

1 0

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object
by Vedran Čačić Aug. 26, 2017

Aug. 26, 2017

Vedran Čačić added the comment: > On the other hand, are there any examples *other* than class and except where this distinction matters? Of course. For example, "for" semantics mentions StopIteration. Of course it doesn't mean "whatever builtins.StopIteration currently refers to". [And in a lot of places it would be possible to say that some builtin is implicit in the statement itself: e.g. while t: is equivalent to while bool(t): for a in b: is equivalent to for a in iter(b): - of course, the docs _don't_ currently say so, so maybe this occurance too should just be deleted. But I still think there are lots of places where docs refer to builtins directly.] ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31283> _______________________________________

1 0