docs December 2014

docs@python.org

39 participants
553 discussions

[issue23040] Better documentation for the urlencode safe parameter
by Wojtek Ruszczewski 24 Dec '14

24 Dec '14

New submission from Wojtek Ruszczewski: The documentation for urlencode() [1] isn't very clear on how the safe parameter is used, it would better not list it together with encoding and error as only applying to strings. [1] https://docs.python.org/3.5/library/urllib.parse.html#urllib.parse.urlencode ---------- assignee: docs@python components: Documentation files: urlencode-safe.diff keywords: patch messages: 232556 nosy: docs@python, wrwrwr priority: normal severity: normal status: open title: Better documentation for the urlencode safe parameter type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37426/urlencode-safe.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23040> _______________________________________

3 7

[issue23110] Document if argument to Py_SetPath requires static storage.
by Robert Snoeberger 24 Dec '14

24 Dec '14

New submission from Robert Snoeberger: The documentation for the Py_SetPath API does not indicate if the argument should point to a wide character array in static storage. However, the documentation for Py_GetPath says, "The returned string points into static storage; the caller should not modify its value." This leads me to believe that static storage is required for Py_SetPath. The documentation for similar API functions, Py_SetPythonHome and Py_SetProgramName, indicates, "The argument should point to a zero-terminated wide character string in static storage whose contents will not change...". ---------- assignee: docs@python components: Documentation messages: 233081 nosy: docs@python, snoeberger priority: normal severity: normal status: open title: Document if argument to Py_SetPath requires static storage. type: enhancement versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23110> _______________________________________

2 1

[issue23105] os.O_SHLOCK and os.O_EXLOCK are not available on Linux
by Sworddragon 23 Dec '14

23 Dec '14

Sworddragon added the comment: I have missed the first part of the documentation and am not sure if something needs really to be changed. But if you think so maybe comments like "These constants are only available on Unix." could be extended by the word "commonly" like "These constants are commonly only available on Unix.". ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23105> _______________________________________

1 0

[issue23105] os.O_SHLOCK and os.O_EXLOCK are not available on Linux
by R. David Murray 23 Dec '14

23 Dec '14

R. David Murray added the comment: The documentation says "Some of them are not available on all platforms. For descriptions of their availability and use, consult the open(2) manual page on Unix or the MSDN on Windows.". The important bit there being "consult the open(2) manual page on Unix" for availability. That said, since the options are grouped and labeled with per-platform availability...but with a slightly different meaning of the word platform...I think the docs could be clarified. Do you have a suggestion for rewording that sentence to make it clearer? ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python, r.david.murray versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23105> _______________________________________

1 0

Small bug in documentation menu
by Bas van den Heuvel 23 Dec '14

23 Dec '14

Hi, I discovered a small bug in the documentation. When you visit the main documentation page of Python 3.4, the menu says that Python 3.3 is stable and that 3.5 is in development. WHen you then click on 3.5, it says Python 3.4 is stable. WHen you now return to 3.4 and then click on 3.3, it says that Python 3.4 is in development. It probably got left behind in updating documentation, but this was kind of confusing for me. Thank you. Bas

1 0

Re: [docs] 'codecs' module docs improvements (issue 19548)
by walter＠livinglogic.de 23 Dec '14

23 Dec '14

http://bugs.python.org/review/19548/diff/13486/Doc/library/codecs.rst File Doc/library/codecs.rst (right): http://bugs.python.org/review/19548/diff/13486/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:204: (to be encoded by the codec), and ``'\ufffd'`` (``'�'``) for I think the literal replacement character should be removed in this spot, as it's unclean how this character will appear in the target document. http://bugs.python.org/review/19548/

1 0

Re: [docs] 'codecs' module docs improvements (issue 19548)
by vadmium+py＠gmail.com 23 Dec '14

23 Dec '14

Addressed most of the comments in patch v3; there were a few of Nick’s I wasn’t sure on https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst File Doc/library/codecs.rst (right): https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:24: bytes to bytes. On 2014/12/22 16:22:05, Nick Coghlan wrote: > I like the idea of expanding on this paragraph. I suggest we make "text > encoding" a defined term in the glossary, and adjust this addition to be: > > Most standard codecs are :term:`text encodings <text encoding>`, which encode > text to bytes, but there are also codecs that encode text to text, and bytes to > bytes. Custom codecs beyond those provided in the standard library may convert > between arbitrary types." Added, except for the last sentence. Can they really convert between arbitrary types, or just sequences of arbitrary types? There are already plenty of bugs and undocumented quirks with the existing non-text encodings, so I wonder if allowing even stranger types is a good idea right now. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:54: is not reversible, which doesn't play well with module reloading. On 2014/12/22 16:22:05, Nick Coghlan wrote: > I suggest pulling this caveat out into a "note". As far as phrasing goes, > something a little more formal may be good. Perhaps: > > "Search function registration is not currently reversible, which may cause > problems in some cases, such as unit testing or module reloading" Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:198: suitable replacement marker such as ``b'?'`` in or ``'\ufffd'``. On 2014/12/22 16:22:05, Nick Coghlan wrote: > With the new defined term, this error handling function should gain a sentence > to indicate that it's only applicable to text encodings. (There may actually be > cases where it's usable for bytes->bytes or text->text, but if that's actually > the case, we can figure out how to fix the issue later. For the time being, I > think it's more important to clearly document the text encoding case) Added. > The substitution can then be clarified to say that b'?' is produced when > encoding, and '\ufffd' when decoding (we can also embed the actual encoded code > point in the documentation here, in addition to the \u escape). Actually my change to b'?' was misleading. See revised text. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:210: unencodable character is replaced by an appropriate XML character reference. On 2014/12/22 16:22:05, Nick Coghlan wrote: > Also text encoding specific. Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:216: unencodable character is replaced by a backslashed escape sequence. On 2014/12/22 16:22:05, Nick Coghlan wrote: > Also text encoding specific. Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:221: unencodable character is replaced by a ``\N{...}`` escape sequence. On 2014/12/22 16:22:05, Nick Coghlan wrote: > Also text encoding specific. Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:229: .. function:: open(filename, mode='r'[, encoding[, errors[, buffering]]]) On 2014/12/22 14:11:11, berkerpeksag wrote: > Could you also convert this to use Python 3 style parameter like the other > functions? > > For example: > > open(filename, mode='r' encoding=None, errors='strict', buffering=None) > > (Not sure all default valures are correct) Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:238: No automatic conversion of ``'\n'`` is done on reading and writing. On 2014/12/22 16:22:05, Nick Coghlan wrote: > We should also explicitly note here that *this* open uses the StreamReader and > StreamWriter classes provided by the CodecInfo module, *not* the general purpose > IO classes provided by the io module. Added, including a unit test asserting it is always StreamReaderWriter. > This means that 'encoding' here can be any arbitrary registered codec, rather > than necessarily being a text encoding as it is for the io module (and hence the > builtin open function) Clarified below, though still with the requirement that it has to encode to bytes. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:241: Only the codecs whose encoded form is bytes are supported. On 2014/12/22 16:22:05, Nick Coghlan wrote: > It's worth explicitly noting here that the types supported by the file-like > object will depend on the codec used. Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:261: a text stream. On 2014/12/22 16:22:05, Nick Coghlan wrote: > I'm going to have to look at the implementation to confirm whether this more > specific version is accurate, as I suspect it isn't quite right in the case > where data_encoding == file_encoding. EncodedFile() implementation just blindly calls StreamRecoder, and StreamRecoder doesn’t appear to do any optimization or anything either. I think you’d definitely need to do a full decode and recode if the user specified a non-strict error handler. > For the case where they're different, we may want to use the word "transcoding". Okay, done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:267: error occurs. On 2014/12/22 16:22:05, Nick Coghlan wrote: > Since this factory function produces a StreamRecoder instance, a cross reference > may be useful. Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:329: To simplify and standardize error handling, On 2014/12/22 16:22:05, Nick Coghlan wrote: > I suggest giving this section on error handlers its own subheading and label, so > it can be referenced directly. Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:332: and implemented by all standard Python codecs: On 2014/12/22 16:22:05, Nick Coghlan wrote: > It may be worthwhile adding cross references back to the functions implementing > each error handler. > > For example, finishing with: "(Implemented in :func:`strict_errors`)" Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:337: | Value | Meaning | On 2014/12/22 16:22:05, Nick Coghlan wrote: > I believe this table needs to be split in two, with replace through to > surrogateescape being restricted in applicability to text encodings. Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:361: | | surrogate code ranging from U+DC80 to U+DCFF. | On 2014/12/22 14:11:11, berkerpeksag wrote: > ``U+DC80`` to ``U+DCFF`` Done, including other instances in the file. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:363: | | same byte when the ``surrogateescape`` error | On 2014/12/22 14:11:11, berkerpeksag wrote: > ``'surrogateescape'`` Done, including other references in the page. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:469: by providing the *errors* keyword argument. These parameters are predefined: On 2014/12/22 16:22:05, Nick Coghlan wrote: > Given the new link target for the error handler tables, I'd replace this > bulleted list with a cross-reference. Good idea, done https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:489: :func:`register_error`. On 2014/12/22 16:22:05, Nick Coghlan wrote: > This paragraph can move to the shared section on error handlers. Already in the section, so removed. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:540: by providing the *errors* keyword argument. These parameters are predefined: On 2014/12/22 16:22:05, Nick Coghlan wrote: > As above - it's likely worth replacing the repeated list with a cross-reference. Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:554: :func:`register_error`. On 2014/12/22 16:22:05, Nick Coghlan wrote: > With this paragraph moved to the common section, it can be dropped here. Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:617: *stream* must be a file-like object open for writing. On 2014/12/22 16:22:05, Nick Coghlan wrote: > I suggest finishing this sentence as "... writing text or binary data, as > appropriate for the specific codec". Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:620: providing the *errors* keyword argument. These parameters are predefined: On 2014/12/22 16:22:05, Nick Coghlan wrote: > As with the Incremental* APIs, I'm a fan of consolidating the error handler > documentation, and linking to it where appropriate. Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:650: the :meth:`write` method). Does not work on byte encoders. On 2014/12/22 16:22:05, Nick Coghlan wrote: > The new caveat needs to be clarified: what does "Does not work" mean? What > counts as a "byte encoder" in this context? > > If the issue is "May not be present for codecs other than text encodings", then > that's what we should say. I think the trouble is that it is present (via inheritance I assume) for the byte-to-byte codecs, but the code assumes the input is text strings. Will change to something like “The standard bytes-to-bytes codecs do not support this method”. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:684: *stream* must be a file-like object open for reading. On 2014/12/22 16:22:05, Nick Coghlan wrote: > See the StreamWriter comments for suggested phrasing here. Applied https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:708: characters or bytes to return. The :func:`read` method will On 2014/12/22 16:22:05, Nick Coghlan wrote: > characters -> code points (due to complexities in the definition of what > actually constitutes a Unicode characters, str's are code point arrays rather > than character arrays) Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:713: number of encoded bytes or characters to read On 2014/12/22 16:22:05, Nick Coghlan wrote: > characters -> code points again. Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:1242: | | | decoding ``b''`` | On 2014/12/22 16:22:05, Nick Coghlan wrote: > This should be clear on what b'' gets decoded to. I might drop that bit for now. I found that b"".decode("undefined") -> "", but now I find codecs.decode(b"", "undefined") raises an exception. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:1250: | | | Latin-1 source code. | On 2014/12/22 16:22:05, Nick Coghlan wrote: > This description should be caveated with the fact that Python 3 uses UTF-8 by > default, and relying on that is preferable to unicode_escape in most cases where > Python 2 source compatibility isn't needed and a utf-8 encoding cookie can't be > used for some reason. Pointed out that UTF-8 is the default, but the second half went over my head. What is preferable to unicode_escape when you have UTF-8 source code? https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:1256: | | | .. deprecated:: 3.3 | On 2014/12/22 16:22:05, Nick Coghlan wrote: > May be worth cross referencing PEP 393 here to explain this deprecation. Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:1265: to :class:`bytes` mappings. They are not supported by :meth:`bytes.decode`. On 2014/12/22 16:22:05, Nick Coghlan wrote: > Perhaps append "(which is expected to produce :class:`str` output)" to the new > sentence? Done. https://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newc… Doc/library/codecs.rst:1320: mapping. It is not supported by :meth:`str.encode`. On 2014/12/22 16:22:05, Nick Coghlan wrote: > Perhaps append "(which is expected to produce :class:`bytes` output)"? Done. https://bugs.python.org/review/19548/

1 0

Re: [docs] 'codecs' module docs improvements (issue 19548)
by ncoghlan＠gmail.com 22 Dec '14

22 Dec '14

I definitely like the proposed changes overall, especially splitting CodecInfo out into a separately documented class. Lots more detailed feedback inline, including some genuien questions where I don't know the answer off the top of my head myself, and it isn't a quick check at the interactive prompt to confirm the current behaviour. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst File Doc/library/codecs.rst (right): http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:24: bytes to bytes. I like the idea of expanding on this paragraph. I suggest we make "text encoding" a defined term in the glossary, and adjust this addition to be: Most standard codecs are :term:`text encodings <text encoding>`, which encode text to bytes, but there are also codecs that encode text to text, and bytes to bytes. Custom codecs beyond those provided in the standard library may convert between arbitrary types." http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:54: is not reversible, which doesn't play well with module reloading. I suggest pulling this caveat out into a "note". As far as phrasing goes, something a little more formal may be good. Perhaps: "Search function registration is not currently reversible, which may cause problems in some cases, such as unit testing or module reloading" http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:198: suitable replacement marker such as ``b'?'`` in or ``'\ufffd'``. With the new defined term, this error handling function should gain a sentence to indicate that it's only applicable to text encodings. (There may actually be cases where it's usable for bytes->bytes or text->text, but if that's actually the case, we can figure out how to fix the issue later. For the time being, I think it's more important to clearly document the text encoding case) The substitution can then be clarified to say that b'?' is produced when encoding, and '\ufffd' when decoding (we can also embed the actual encoded code point in the documentation here, in addition to the \u escape). http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:210: unencodable character is replaced by an appropriate XML character reference. Also text encoding specific. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:216: unencodable character is replaced by a backslashed escape sequence. Also text encoding specific. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:221: unencodable character is replaced by a ``\N{...}`` escape sequence. Also text encoding specific. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:238: No automatic conversion of ``'\n'`` is done on reading and writing. We should also explicitly note here that *this* open uses the StreamReader and StreamWriter classes provided by the CodecInfo module, *not* the general purpose IO classes provided by the io module. This means that 'encoding' here can be any arbitrary registered codec, rather than necessarily being a text encoding as it is for the io module (and hence the builtin open function) http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:241: Only the codecs whose encoded form is bytes are supported. It's worth explicitly noting here that the types supported by the file-like object will depend on the codec used. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:261: a text stream. I'm going to have to look at the implementation to confirm whether this more specific version is accurate, as I suspect it isn't quite right in the case where data_encoding == file_encoding. For the case where they're different, we may want to use the word "transcoding". http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:267: error occurs. Since this factory function produces a StreamRecoder instance, a cross reference may be useful. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:329: To simplify and standardize error handling, I suggest giving this section on error handlers its own subheading and label, so it can be referenced directly. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:332: and implemented by all standard Python codecs: It may be worthwhile adding cross references back to the functions implementing each error handler. For example, finishing with: "(Implemented in :func:`strict_errors`)" http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:337: | Value | Meaning | I believe this table needs to be split in two, with replace through to surrogateescape being restricted in applicability to text encodings. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:368: In addition, the following error handlers are specific to Unicode encoding With the above table split in two, the phrasing in this introductory paragraph may need tweaking. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:469: by providing the *errors* keyword argument. These parameters are predefined: Given the new link target for the error handler tables, I'd replace this bulleted list with a cross-reference. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:489: :func:`register_error`. This paragraph can move to the shared section on error handlers. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:540: by providing the *errors* keyword argument. These parameters are predefined: As above - it's likely worth replacing the repeated list with a cross-reference. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:554: :func:`register_error`. With this paragraph moved to the common section, it can be dropped here. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:617: *stream* must be a file-like object open for writing. I suggest finishing this sentence as "... writing text or binary data, as appropriate for the specific codec". http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:620: providing the *errors* keyword argument. These parameters are predefined: As with the Incremental* APIs, I'm a fan of consolidating the error handler documentation, and linking to it where appropriate. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:650: the :meth:`write` method). Does not work on byte encoders. The new caveat needs to be clarified: what does "Does not work" mean? What counts as a "byte encoder" in this context? If the issue is "May not be present for codecs other than text encodings", then that's what we should say. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:684: *stream* must be a file-like object open for reading. See the StreamWriter comments for suggested phrasing here. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:708: characters or bytes to return. The :func:`read` method will characters -> code points (due to complexities in the definition of what actually constitutes a Unicode characters, str's are code point arrays rather than character arrays) http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:713: number of encoded bytes or characters to read characters -> code points again. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:760: In addition to the above methods, the :class:`StreamReader` must also inherit Not a new issue in the patch, but "inherit" doesn't strike me as being the right word here (I'm also not sure the statement is even true any more). http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:1242: | | | decoding ``b''`` | This should be clear on what b'' gets decoded to. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:1250: | | | Latin-1 source code. | This description should be caveated with the fact that Python 3 uses UTF-8 by default, and relying on that is preferable to unicode_escape in most cases where Python 2 source compatibility isn't needed and a utf-8 encoding cookie can't be used for some reason. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:1256: | | | .. deprecated:: 3.3 | May be worth cross referencing PEP 393 here to explain this deprecation. http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:1265: to :class:`bytes` mappings. They are not supported by :meth:`bytes.decode`. Perhaps append "(which is expected to produce :class:`str` output)" to the new sentence? http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:1320: mapping. It is not supported by :meth:`str.encode`. Perhaps append "(which is expected to produce :class:`bytes` output)"? http://bugs.python.org/review/19548/

1 0

Re: [docs] 'codecs' module docs improvements (issue 19548)
by berker.peksag＠gmail.com 22 Dec '14

22 Dec '14

http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst File Doc/library/codecs.rst (right): http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:229: .. function:: open(filename, mode='r'[, encoding[, errors[, buffering]]]) Could you also convert this to use Python 3 style parameter like the other functions? For example: open(filename, mode='r' encoding=None, errors='strict', buffering=None) (Not sure all default valures are correct) http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:361: | | surrogate code ranging from U+DC80 to U+DCFF. | ``U+DC80`` to ``U+DCFF`` http://bugs.python.org/review/19548/diff/13481/Doc/library/codecs.rst#newco… Doc/library/codecs.rst:363: | | same byte when the ``surrogateescape`` error | ``'surrogateescape'`` http://bugs.python.org/review/19548/

1 0

[issue19539] The 'raw_unicode_escape' codec buggy + not appropriate for Python 3.x
by Martin Panter 22 Dec '14

22 Dec '14

Martin Panter added the comment: [Edit Error: 'utf8' codec can't decode byte 0xe2 in position 212: invalid continuation byte] Re-reading the suggested description, it struck me that for encoding, this is redundant with the “backslashreplace” error handler: >>> test = "".join(map(chr, range(sys.maxunicode + 1))) >>> test.encode("raw-unicode-escape") == test.encode("latin-1", "backslashreplace") True However, decoding also seems similar to “unicode_escape”, except that only \uXXXX and \UXXXXXXXX seem to be supported. Maybe there should be a warning that backslashes are not escaped: >>> "\\u005C".encode("raw-unicode-escape").decode("raw-unicode-escape") '\\' ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19539> _______________________________________

1 0

← Newer
1
...
45
46
47
48
49
50
51
...
56
Older →

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs December 2014