New submission from beeNuts <jeff.adams(a)linux.com>:
Issue #14144, with the title "urllib2 HTTPRedirectHandler not forwarding POST data in redirect" was recently closed with these comments:
"This could be cookbook recipe style example, if it's utility
value is high. I am closing this issue as I feel that the requirement may not be addressed by a change. If there is patch for HowTo, we can tackle that in another issue. Thank you for contribution."
The decision that documents on this issue were preferable to a patch seems like a fair compromise, especially considering that the RFC is decidedly ambiguous.I was wondering if the HowTo would be forthcoming?
It seems to me that the value/utility would certainly be high. I'd submit it myself but I'm so new to Python that I don't trust my ability to do it correctly. It's something I would find highly useful, though.
----------
assignee: docs@python
components: Documentation
messages: 156080
nosy: beerNuts, docs@python
priority: normal
severity: normal
status: open
title: urllib2 HowTo for overriding post/3xx behavior.
versions: Python 3.3
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue14338>
_______________________________________
New submission from Giampaolo Rodola':
In Python 2 the distinction between open() and codes.open() was clear because 'encoding' and 'errors' args were provided by codecs.open only.
This is no longer the case in Python 3 since both args are provided also by open().
I'm probably missing something but regardless I think codecs.open doc [1] should be more clear as to when and why (say) codecs.open(file, encoding='utf8', errors='ignore') should be preferred over open(file, encoding='utf8', errors='ignore').
[1] http://docs.python.org/3/library/codecs.html#codecs.open
----------
assignee: docs@python
components: Documentation
messages: 184303
nosy: docs@python, ezio.melotti, giampaolo.rodola
priority: normal
severity: normal
status: open
title: Difference between open and codecs.open
versions: Python 3.2, Python 3.3, Python 3.4
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue17437>
_______________________________________
New submission from Franklin? Lee:
>From `compile`'s doc:
"Compile the source into a code or AST object."
The docs don't say how to compile into an AST object with `compile`, though. As it says later:
"If you want to parse Python code into its AST representation, see ast.parse()."
I checked 3.4-3.2, 3.0, 2.7, and 2.6. Versions before 3.4, and version 2.6, are missing the `ast.parse` line, but still have the first line.
----------
assignee: docs@python
components: Documentation
messages: 266311
nosy: docs@python, leewz
priority: normal
severity: normal
status: open
title: `compile` doesn't compile into an AST object as specified
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue27119>
_______________________________________
New submission from Antoine Pitrou <pitrou(a)free.fr>:
Sébastien, would you like to provide an updated version of that file? The current contents look hopelessly outdated.
----------
assignee: docs@python
components: Documentation
messages: 124024
nosy: docs@python, pitrou, sable
priority: normal
severity: normal
stage: needs patch
status: open
title: Misc/AIX-NOTES needs updating
versions: Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue10709>
_______________________________________
New submission from R. David Murray <rdmurray(a)bitdance.com>:
And I wish I knew what those were.
----------
assignee: docs@python
components: Documentation
messages: 162513
nosy: docs@python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: tutorial should use best practices in user defined execeptions section
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue15034>
_______________________________________
New submission from Kevin Norris <nykevin.norris(a)gmail.com>:
The 3.x datetime documentation contains the following footnote:
> In other words, date1 < date2 if and only if date1.toordinal() < date2.toordinal(). In order to stop comparison from falling back to the default scheme of comparing object addresses, date comparison normally raises TypeError if the other comparand isn’t also a date object. However, NotImplemented is returned instead if the other comparand has a timetuple() attribute. This hook gives other kinds of date objects a chance at implementing mixed-type comparison. If not, when a date object is compared to an object of a different type, TypeError is raised unless the comparison is == or !=. The latter cases return False or True, respectively.
But in 3.x, comparison no longer falls back to comparing object addresses. Also, some of the comments on issue 8005 seem to suggest that this footnote is not actually true in 3.x (aside from the first sentence, of course). But regardless, the footnote should not refer to a long dead interpreter behavior as if it were still around.
----------
assignee: docs@python
components: Documentation
messages: 323314
nosy: Kevin.Norris, docs@python
priority: normal
severity: normal
status: open
title: datetime's documentation refers to "comparison [...] falling back to the default scheme of comparing object addresses"
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue34365>
_______________________________________
New submission from Wenzel Jakob:
Hi,
over the last few months, I've been developing a library ("pybind11") for creating Python bindings of C++ code. It is similar in spirit to Boost.Python but uses a very different minimalist approach.
It would be fantastic to get this library listed here: https://docs.python.org/3/faq/extending.html
The purpose of this ticket is that somebody with permissions might add it to this page.
pybind11 is here: https://github.com/wjakob/pybind11
Please let me know if you need any additional information.
Thank you,
Wenzel
----------
assignee: docs@python
components: Documentation
messages: 249865
nosy: docs@python, wenzel
priority: normal
severity: normal
status: open
title: List pybind11 binding generator
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue25006>
_______________________________________
New submission from Éric Araujo <merwok(a)netwok.org>:
argparse helpfully makes its messages with gettext.gettext. The docs should explain how to benefit from that in one’s program.
----------
assignee: docs@python
components: Documentation
messages: 122358
nosy: bethard, docs@python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Write argparse i18n howto
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue10529>
_______________________________________
New submission from Роман Донченко <DXDragon(a)yandex.ru>:
The language reference says this in section 3.2:
~
Built-in functions
A built-in function object is a wrapper around a C function. Examples of built-in functions are len() and math.sin() <...> Special read-only attributes: <...> __self__ is set to None (but see the next item) <...>.
~
That is not the case:
ActivePython 3.2.2.3 (ActiveState Software Inc.) based on
Python 3.2.2 (default, Sep 8 2011, 10:55:13) [MSC v.1500 64 bit (AMD64)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> len.__self__
<module 'builtins' (built-in)>
>>> open.__self__
<module 'io' (built-in)>
>>> import math
>>> math.sin.__self__
<module 'math' (built-in)>
----------
assignee: docs@python
components: Documentation
messages: 153287
nosy: SpecLad, docs@python
priority: normal
severity: normal
status: open
title: __self__ on built-in functions is not as documented
type: behavior
versions: Python 3.2
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue14003>
_______________________________________
New submission from Anthony Green:
The documentation at https://docs.python.org/3/library/threading.html#threading.Thread.is_alive relates:
> The module function enumerate() returns a list of all alive threads.
The documentation at https://docs.python.org/3/library/threading.html#threading.enumerate relates:
> Return a list of all Thread objects currently alive. The list includes daemonic threads, dummy thread objects created by current_thread(), and the main thread.
This is a contradiction, since if the main thread has stopped, is_alive(main_thread) will return False, but it will still be included in the list returned by threading.enumerate.
Note that this is not a TOCTTOU issue. The issue is that enumerate actually includes "all alive threads, plus one [or more? I can't tell from the code] other[s]."
----------
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue25821>
_______________________________________