Mailman 3 February 2016 - docs

[issue26209] TypeError in smtpd module with string arguments
by Terry J. Reedy Feb. 3, 2016

Feb. 3, 2016

Terry J. Reedy added the comment: Doc fixes unrelated to security fixes are not applied to security-fix-only versions. ---------- versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26209> _______________________________________

1 0

[issue26256] Fast decimalisation and conversion to other bases
by STINNER Victor Feb. 3, 2016

Feb. 3, 2016

STINNER Victor added the comment: "It's great to have this stuff, but I don't think it belongs in core Python: I'd much rather that the core Python integer implementation remain simple, portable and low-maintenance, and work well for the domain it's intended for: small-to-medium size integers." Yeah I agree. Maybe we need to explain that somewhere? In the devguide? Even in Python doc? I know that they are super crazy^W fast algorithm to handle very large numbers (hum, what is large? more than 4096 bits?), but they are usually very complex. Projects like GMP have ultra fast code with optimizations in assemblers. Having assembler implementation is clearly out of the scope of Python. "Maybe I should change the issue then to "documentation missing": it nowhere says in the documentation that decimal has optimized multiprecision computations." Well, nowhere means: https://docs.python.org/dev/whatsnew/3.3.html#decimal Usually, we don't document performances of a function, maybe only its complexity. -- You may move to the numpy community which is problably more keen on such optimization than the Python *core*. ---------- nosy: +haypo _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26256> _______________________________________

2 1

[issue26256] Fast decimalisation and conversion to other bases
by Jurjen N.E. Bos Feb. 3, 2016

Feb. 3, 2016

Jurjen N.E. Bos added the comment: That reference you gave says that the binary version is faster than the Python version, but here the _complexity_ actually changed by a lot. Only people who know the library by name will notice that it is this fast. But you are right, for 99% of the people it doesn't make much of a difference. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26256> _______________________________________

1 0

[issue26256] Fast decimalisation and conversion to other bases
by Jurjen N.E. Bos Feb. 3, 2016

Feb. 3, 2016

Jurjen N.E. Bos added the comment: OMG is decimal that fast? Maybe I should change the issue then to "documentation missing": it nowhere says in the documentation that decimal has optimized multiprecision computations. It only says that precision "can be as large as needed for a given problem", but I never realized that that included millions of digits. It computed to my complete surprise 2**2**29 to full precision (161 million decimal digits) in about a minute. That smells suspiciously like FFT style multiplication, which implies that it is way more sophisticated than integer multiplication! I suggest that the documentation of the decimal module recommends using decimal for multiprecision computations, as long as you use the builtin version. ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26256> _______________________________________

1 0

problem in installing python
by Salony Permanand Feb. 3, 2016

Feb. 3, 2016

sir, I downloaded different version of python but no one is installed on my pc because of same installation error each time having error code 2203. Please solve it... Thanking you Salony Permanand IIT Allahabad 7275838206

1 0

[issue26209] TypeError in smtpd module with string arguments
by Lorenzo Ancora Feb. 3, 2016

Feb. 3, 2016

Lorenzo Ancora added the comment: (msg259229) Terry J. Reedy i Suggest that a standard and globally accepted scheme to manage IPv4 addresses is: "Host:PortNumber" --> (host, PortNumber) "Host" --> (host, DefaultPortNumber) "IP:PortNumber" --> (host, PortNumber) "IP" --> (host, DefaultPortNumber) ...where DefaultPortNumber is protocol and system dependent (IANA standard, see the SMTP line in: http://www.iana.org/assignments/service-names-port-numbers/service-names-po…). A simple research reveals that all versions of the module are (sadly) poorly documented, but the module is an interface to a very important protocol that indeed must be offered by the standard library. The only little suggestion in the documentation of the module is: https://docs.python.org/3.6/library/socket.html#socket.socket.accept ...from a one-word link in: https://docs.python.org/3.6/library/smtpd.html#smtpd.SMTPChannel.addr Which has only an indirect relation with the object itself. Many users may not recognize the cause of the error if the documentation doesn't explicitate the information to correctly initialize the core objects of the module. I also Suggest that at least the object should return an helpful error in newer versions of Python. Thank you for your efforts guys. :-) ---------- components: +Library (Lib) versions: +Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26209> _______________________________________

1 0

Type on the 26.1 typing page
by Jon Tetlak Feb. 2, 2016

Feb. 2, 2016

26.1. typing — Support for type hints — Python 3.5.1 documentation https://docs.python.org/3/library/typing.html At the top section, in the last sentence, ..."expected to by of type str"... should say *be *instead of *by *correct? Really minor typo, but found it and figured I would pass it along.

2 1

Python tutorial - example on "range" function (chapter Built-in Functions)
by Cristian Dragan (cdragan) Feb. 2, 2016

Feb. 2, 2016

Hi, According to the definition of the range function (within the Python tutorial 2.7.11) I assume that >>> range(1, 0) Should have 1 element: [1], while the tutorial specify: []. Please let me know if I misunderstood the definition of the "range" function. Thank you very much, Cristian Dragan

2 1

[issue23200] Clarify max_length and flush() for zlib decompression
by Martin Panter Feb. 2, 2016

Feb. 2, 2016

New submission from Martin Panter: This simple patch documents that max_length has to be non-zero. The implementation actually uses zero as a special value to indicate max_length was not specified. Also, I wonder what the point of the Decompressor.flush() method is. Reading the module code and zlib manual, it looks like it would return the same data as decompressor.decompress(decompressor.unconsumed_tail), except that it uses the Z_FINISH flag instead of Z_SYNC_FLUSH, so that zlib can optimize by assuming no more data is to be processed. Since unconsumed_tail is read-only and only relevant when using max_length, and flush does not support max_length, I wonder if the flush() method should be deprecated. To further test this theory, I modified the test_zlib.py file so that all appropriate flush() calls are equivalent to this: self.assertFalse(dco.flush()) and the tests all still pass. BTW, it looks to me like zlib_Decompress_flush_impl() is setting avail_out too high (blessing unallocated memory) when the total length is more than half of UNIT_MAX, but I am not in a position to test this. ---------- assignee: docs@python components: Documentation files: max_length.patch keywords: patch messages: 233709 nosy: docs@python, vadmium priority: normal severity: normal status: open title: Clarify max_length and flush() for zlib decompression versions: Python 3.4 Added file: http://bugs.python.org/file37650/max_length.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23200> _______________________________________

3 9

[issue26244] zlib.compressobj level default value documentation
by Aviv Palivoda Feb. 2, 2016

Feb. 2, 2016

New submission from Aviv Palivoda: In the zlib.compressobj documentation the default value of the compress level is -1 while it is actually 6. patch is included ---------- assignee: docs@python components: Documentation, Extension Modules files: zlib-compressobj-level-doc.patch keywords: patch messages: 259267 nosy: docs@python, nadeem.vawda, palaviv, twouters priority: normal severity: normal status: open title: zlib.compressobj level default value documentation versions: Python 3.6 Added file: http://bugs.python.org/file41761/zlib-compressobj-level-doc.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26244> _______________________________________

3 5