[issue20751] Harmonize descriptor protocol documentation: direct call, super binding with Descriptor Howto docs
Jan Kaliszewski added the comment: Sure. But don't you think there should be ``.__get__(a, type(a))`` rather than ``.__get__(a, A)``? Then the whole statement would be true regardless of whether A is the actual type of a, or only a superclass of the type of a. That would also be more consistent with the second point of the description, i.e., the one about *Instance Binding* (where we have ``type(a).__dict__['x'].__get__(a, type(a))``). Also, I believe that ``type(a).__mro__`` would be more consistent (than ``a.__class__.mro``) with that point. -- ___ Python tracker <https://bugs.python.org/issue20751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7796] No way to find out if an object is an instance of a namedtuple
Jan Kaliszewski added the comment:
On python-ideas I have proposed an ABC being also a kind of a mix-in,
potentially making namedtuple subclassing (with custom methods etc.) more
convenient, e.g.:
class MyRecord(namedtuple.abc):
_fields = 'x y z'
def _my_custom_method(self):
return list(self._asdict().items())
or
class MyAbstractRecord(namedtuple.abc):
def _my_custom_method(self):
return list(self._asdict().items())
class AnotherAbstractRecord(MyAbstractRecord):
def __str__(self):
return '<<<{}>>>'.format(super().__str__())
class MyRecord2(MyAbstractRecord):
_fields = 'a, b'
class MyRecord3(AnotherAbstractRecord):
_fields = 'p', 'q', 'r'
Here is an experimental monkey-patcher adding the 'abc' attribute to namedtuple:
http://dpaste.org/T9w6/
I am not sure if it is worth preparing an actual patch based on it. If you
think it is I could prepare one.
--
nosy: +zuo
___
Python tracker
<http://bugs.python.org/issue7796>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7796] No way to find out if an object is an instance of a namedtuple
Jan Kaliszewski added the comment: PS. Newer, shorter version: http://dpaste.org/2aiQ/ -- ___ Python tracker <http://bugs.python.org/issue7796> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7796] No way to find out if an object is an instance of a namedtuple
Jan Kaliszewski added the comment: Thank you. Raymond is against the idea so I don't know if it makes sense to create the real patch for now (it would patch the collections module and, I suppose, addming tests, docs etc.). Anyway, if somebody would be interested in the idea, the newest version of the draft is here: http://dpaste.org/qyKv/. -- ___ Python tracker <http://bugs.python.org/issue7796> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7796] No way to find out if an object is an instance of a namedtuple
Jan Kaliszewski added the comment: PS. For the record: the final recipe is here: http://code.activestate.com/recipes/577629-namedtupleabc-abstract-base-class-mix-in-for-named/ -- ___ Python tracker <http://bugs.python.org/issue7796> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10682] With '*args' or even bare '*' in def/call argument list, trailing comma causes SyntaxError
New submission from Jan Kaliszewski :
Let examples speak:
def x(a, z): pass # this is ok
def x(a, z,): pass # this is ok
def x(a, *, z): pass # this is ok in Py3k
def x(a, *, z,): pass # but this causes SyntaxError (!)
def x(a, *args): pass # this is ok
def x(a, *args,): pass # but this causes SyntaxError
def x(a, **kwargs): pass # this is ok
def x(a, **kwargs,): pass # but this causes SyntaxError
def x(a, *args, z): pass # this is ok in Py3k
def x(a, *args, z,): pass # but this causes SyntaxError (!)
And similarly -- calls:
def x(*args, **kwargs): pass
x(1, *(2,3,4))# this is ok
x(1, *(2,3,4),) # but this causes SyntaxError
x(1, **{5: 6})# this is ok
x(1, **{5: 6},) # but this causes SyntaxError
x(1, 2, 3, 4, z=5)# this is ok
x(1, *(2,3,4), z=5) # this is ok in Py2.6+ and Py3k
x(1, *(2,3,4), z=5,) # but this causes SyntaxError (!)
Similar problem was discussed years ago as a docs bug -- see: issue798652, but
-- as inconsistent with intuition and a general Python rule that trailing
commas are ok in argument lists and sequence literals (except empty ones) -- it
seems to be rather a language syntax definition issue.
Now, after introducing new syntax possibilities in Py2.6 and especially Py3k
(see the examples above), the issue is even much more painful.
Also, please consider that Py3k's function annotations encourage to format
argument list in one-argument-per-line-manner:
def my_func(
spam:"Very tasty and nutritious piece of food",
ham:"For experts only",
*more_spam:"Not less tasty and not less nutritious!",
spammish:"Nobody expects this!"='Inquisition',
):
...
--
components: Interpreter Core
messages: 123823
nosy: zuo
priority: normal
severity: normal
status: open
title: With '*args' or even bare '*' in def/call argument list, trailing comma
causes SyntaxError
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue10682>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10682] With '*args' or even bare '*' in def/call argument list, trailing comma causes SyntaxError
Jan Kaliszewski added the comment:
s/**{5: 6}/**{'5': 6}/g (but it's a detail)
--
___
Python tracker
<http://bugs.python.org/issue10682>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10682] With '*args' or even bare '*' in def/call argument list, trailing comma causes SyntaxError
Jan Kaliszewski added the comment: Oops, I see the problem was partly addressed @ issue9232. But: * the proposed patch doesn't fix calls (but defs only), * shouldn't be the issue considered as a bug -- and fixed also in 2.7 and 3.1? -- ___ Python tracker <http://bugs.python.org/issue10682> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9232] Allow trailing comma in any function argument list.
Changes by Jan Kaliszewski : -- nosy: +zuo ___ Python tracker <http://bugs.python.org/issue9232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9232] Allow trailing comma in any function argument list.
Jan Kaliszewski added the comment: >From 10682: The patch proposed in this (#9232) issue does not fix call syntax >but def sytax only. I think it should fix call sytax as well (see code >examples in #10682). -- ___ Python tracker <http://bugs.python.org/issue9232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9232] Allow trailing comma in any function argument list.
Jan Kaliszewski added the comment: python-dev discussion continuation: http://mail.python.org/pipermail/python-dev/2010-December/106770.html -- ___ Python tracker <http://bugs.python.org/issue9232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7764] dictview
Changes by Jan Kaliszewski : -- title: Doc for itertools recipe consume is complicated and less efficient -> dictview versions: -Python 2.6, Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue7764> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7764] Doc for itertools recipe consume is complicated and less efficient
Changes by Jan Kaliszewski : -- title: dictview -> Doc for itertools recipe consume is complicated and less efficient ___ Python tracker <http://bugs.python.org/issue7764> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7764] Doc for itertools recipe consume is complicated and less efficient
Jan Kaliszewski added the comment: (sorry! typed into a wrong field) -- nosy: +zuo versions: +Python 2.6, Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue7764> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7771] dict view comparison methods are not documented
New submission from Jan Kaliszewski : Dictionary views documentation (e.g. http://docs.python.org/3.1/library/stdtypes.html#dictionary-view-objects) contains nothing about comparison (> >= < <= == !=) operations. -- assignee: georg.brandl components: Documentation messages: 98240 nosy: georg.brandl, zuo severity: normal status: open title: dict view comparison methods are not documented versions: Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue7771> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7788] segfault when deleting from a list using slice with very big `step' value
New submission from Jan Kaliszewski : del list_instance([start : stop : very_big_step]) causes segfaults... The boundary values seem to be: * start -- near length of the list * stop -- near (-length) of the list * very_big_step -- near sys.maxint Let examples speak... >>> from sys import maxint >>> del range(10)[::maxint] Segmentation fault >>> from sys import maxint >>> del range(10)[13::maxint] >>> del range(10)[12::maxint] >>> del range(10)[11::maxint] >>> del range(10)[10::maxint] >>> del range(10)[9::maxint] Segmentation fault >>> from sys import maxint >>> del range(10)[:-13:maxint] >>> del range(10)[:-12:maxint] >>> del range(10)[:-11:maxint] >>> del range(10)[:-10:maxint] >>> del range(10)[:-9:maxint] Segmentation fault >>> from sys import maxint >>> del range(10)[-8:8:maxint-5] >>> del range(10)[-8:8:maxint-4] >>> del range(10)[-8:8:maxint-3] >>> del range(10)[-8:8:maxint-2] Segmentation fault System Info: * Python 2.5.4 (r254:67916, Apr 4 2009, 17:55:16) * [GCC 4.3.3] on linux2 * sys.maxint == 2147483647, sys.byteorder == 'little' * Processor: Pentium 4 * libc version: 2.9 (2.9-4ubuntu6) -- components: Interpreter Core messages: 98348 nosy: zuo severity: normal status: open title: segfault when deleting from a list using slice with very big `step' value type: crash versions: Python 2.5 ___ Python tracker <http://bugs.python.org/issue7788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7788] segfault when deleting from a list using slice with very big `step' value
Jan Kaliszewski added the comment: ** Erratum ** -- was: del list_instance([start : stop : very_big_step]) causes segfaults... -- should be: del list_instance[start : stop : very_big_step] causes segfaults... ** Post scriptum ** In each example only the last statement causes segmentation fault (previous are OK, and I attached them on purpose -- to show exemplary boundary values when things start going wrong). -- ___ Python tracker <http://bugs.python.org/issue7788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7788] segfault when deleting from a list using slice with very big `step' value
Jan Kaliszewski added the comment: Interesting that in Py2.5... >>> del range(10)[::maxint] ...this causes segfault but in Py2.6 is ok, as well as in Py3.0 (with maxsize insetad of maxint). (That's why I didn't noticed that it concerns newer version than 2.5, and marked only 2.5). But, as Ezio noted, e.g.: >>> del range(10)[5::maxint] ...crashes all of them, e.g: Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22) [GCC 4.3.3] on linux2 >>> from sys import maxsize >>> del list(range(10))[::maxsize] # <- OK >>> del list(range(10))[5::maxsize] Segmentation fault -- ___ Python tracker <http://bugs.python.org/issue7788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7788] segfault when deleting from a list using slice with very big `step' value
Jan Kaliszewski added the comment: PS. Is such a data-dependant segfault considered as security problem? (if it is, maybe Python2.5 shuld be kept in "Versions" list) -- ___ Python tracker <http://bugs.python.org/issue7788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4764] open('existing_dir') -> IOError instance's attr filename is None
New submission from Jan Kaliszewski :
Py2.4 and 2.5 (and probably other 2.x releases too):
>>> try: f=open('existing_dir')
... except IOError, exc: print exc.filename
...
None
(expected result: "existing_dir")
Py3.0 (and possibly 3.1 too):
>>> try: f=open('existing_dir')
... except IOError as exc: print(exc.filename)
...
None
(expected result: "existing_dir")
But no problems with:
open('existing_dir', 'w')
=> exc.filename=='existing_dir'
open('not_existing_file')
=> exc.filename=='not_existing_file'
Guess:
It may be similar to issue #599163
Platform/system info:
[GCC 4.1.2 (Gentoo 4.1.2 p1.0.2)] on linux2
Linux 2.6.25-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz
* Py2.4 == Python 2.4.4 (#1, Oct 7 2008, 13:16:18)
* Py2.5 == Python 2.5.2 (r252:60911, Sep 15 2008, 12:11:51)
* Py3.0 == Python 3.0 (r30:67503, Dec 29 2008, 01:15:48)
--
components: Library (Lib)
messages: 78437
nosy: zuo
severity: normal
status: open
title: open('existing_dir') -> IOError instance's attr filename is None
type: behavior
versions: Python 2.4, Python 2.5, Python 3.0
___
Python tracker
<http://bugs.python.org/issue4764>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20751] Harmonize descriptor protocol documentation: direct call, super binding with Descriptor Howto docs
Jan Kaliszewski added the comment: So the current (after the aforementioned commit) form of the description is: A dotted lookup such as ``super(A, a).x`` searches ``obj.__class__.__mro__`` for a base class ``B`` following ``A`` and then returns ``B.__dict__['x'].__get__(a, A)``. If not a descriptor, ``x`` is returned unchanged. I guess here ``obj`` was supposed to be ``a``. But is the description correct when it comes to what class is used where? I.e., shouldn't it be rather something along the lines of the following: A dotted lookup such as ``super(A, obj).x`` (where ``obj`` is an instance of ``A`` of some other subclass of ``A``) searches ``A.__mro__`` for a base class ``B`` whose `__dict__` contains name ``"x"`` and then returns ``B.__dict__['x'].__get__(obj, type(obj))``. If ``B.__dict__['x']`` is not a descriptor, it is returned unchanged. *** Ad my comment #2 -- yes, it became groundless with time... Minor explanation: when I reported this issue in 2015, the signature of `object.__get__` was documented just as "__get__(self, instance, owner)" (see: https://docs.python.org/3.5/reference/datamodel.html#implementing-descriptors); that's why I wrote about an inconsistency. -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue20751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20751] Harmonize descriptor protocol documentation: direct call, super binding with Descriptor Howto docs
Jan Kaliszewski added the comment: Sorry, a few mistakes distorted my proposal. It should be: A dotted lookup such as ``super(A, obj).x`` (where ``obj`` is an instance of ``A`` or of a subclass of ``A``) searches ``A.__mro__`` for a base class whose `__dict__` contains name ``"x"``, and then returns ``B.__dict__['x'].__get__(obj, type(obj))`` (where ``B`` is that base class). If ``B.__dict__['x']`` is not a descriptor, it is returned unchanged. -- ___ Python tracker <https://bugs.python.org/issue20751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20751] Harmonize descriptor protocol documentation: direct call, super binding with Descriptor Howto docs
Jan Kaliszewski added the comment: I am very sorry, I just noticed another mistake. It should be: A dotted lookup such as ``super(A, obj).x`` (where ``obj`` is an instance of ``A`` or of a subclass of ``A``) searches ``type(obj).__mro__`` for such a base class ``B`` that follows ``A`` and whose :attr:`__dict__` contains the name ``"x"``; then ``B.__dict__['x'].__get__(obj, type(obj))`` is returned. If not a descriptor, ``B.__dict__['x']`` is returned unchanged. -- ___ Python tracker <https://bugs.python.org/issue20751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18533] Avoid error from repr() of recursive dictview
Jan Kaliszewski added the comment:
As I wrote on the list -- IMHO it's still a bug (even though not so painful as
segfault) that should also be fixed in 2.7 and 3.2/3.3. In other cases (such
as `d={}; d[42]=d; repr(d)`) Python does its best to avoid an error -- why in
this case (`d={}; d[42]=d.values(); repr(d)`) should it raise an
exception? IMHO it's an obvious oversight in implementation, not a feature that
anybody would expect.
--
nosy: +zuo
___
Python tracker
<http://bugs.python.org/issue18533>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18858] dummy_threading lacks threading.get_ident() equivalent
New submission from Jan Kaliszewski: In Python 3.3 threading.get_ident() has been added as a public and documented function, but there is no dummy_threading.get_ident(): >>> import threading, dummy_threading >>> threading.get_ident() 139974728402752 >>> dummy_threading.get_ident() Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'get_ident' By the way: it may be worth to check for other possible inconsistencies between avaliable interfaces of threading and dummy_threading. -- components: Library (Lib) messages: 196321 nosy: zuo priority: normal severity: normal status: open title: dummy_threading lacks threading.get_ident() equivalent type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue18858> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19539] The 'raw_unicode_escape' codec buggy + not apropriate for Python 3.x
New submission from Jan Kaliszewski:
It seems that the 'raw_unicode_escape' codec:
1) produces data that could be suitable for Python 2.x raw unicode string
literals and not for Python 3.x raw unicode string literals (in Python 3.x
\u... escapes are also treated literally);
2) seems to be buggy anyway: bytes in range 128-255 are encoded with the
'latin-1' encoding (in Python 3.x it is definitely a bug; and even in Python
2.x the feature is dubious, although at least the Py2's eval() and compile()
functions officially accept 'latin-1'-encoded byte strings...).
Python 3.3:
>>> b = "zażółć".encode('raw_unicode_escape')
>>> literal = b'r"' + b + b'"'
>>> literal
b'r"za\\u017c\xf3\\u0142\\u0107"'
>>> eval(literal)
Traceback (most recent call last):
File "", line 1, in
File "", line 1
SyntaxError: (unicode error) 'utf-8' codec can't decode byte 0xf3 in position
8: invalid continuation byte
>>> b'\xf3'.decode('latin-1')
'ó'
>>> b = "zaż".encode('raw_unicode_escape')
>>> literal = b'r"' + b + b'"'
>>> literal
b'r"za\\u017c"'
>>> eval(literal)
'za\\u017c'
>>> print(eval(literal))
za\u017c
It believe that the 'raw_unicode_escape' codes should either be deprecated and
later removed or be modified to accept only printable ascii characters.
PS. Also, as a side note: neither 'raw_unicode_escape' nor 'unicode_escape'
does escape quotes (see issue #7615) -- shouldn't it be at least documented
explicitly?
--
components: Library (Lib), Unicode
messages: 202505
nosy: ezio.melotti, haypo, zuo
priority: normal
severity: normal
status: open
title: The 'raw_unicode_escape' codec buggy + not apropriate for Python 3.x
versions: Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue19539>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19539] The 'raw_unicode_escape' codec buggy + not apropriate for Python 3.x
Jan Kaliszewski added the comment: Which means that the description "Produce a string that is suitable as raw Unicode literal in Python source code" is (in Python 3.x) no longer true. So, if change/removal is not possible because of internal significance of the codec, I believe that the description should be changed to something like: "For internal use. This codec *does not* produce anything suitable as a raw string literal in Python 3.x source code." -- assignee: -> docs@python components: +Documentation nosy: +docs@python versions: +Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue19539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19548] 'codecs' module docs improvements
New submission from Jan Kaliszewski: When learning about the 'codecs' module I encountered several places in the docs of the module that, I believe, could be improved to be clearer and easier for codecs-begginers: 1. Ad `codecs.encode` and `codecs.decode` descriptions: I believe it would be worth to mention that, unlike str.encode()/bytes.decode(), these functions (and all their counterparts in the classes the module contains) support not only "traditional str/bytes encodings", but also bytes-to-bytes as well as str-to-str encodings. 2. Ad 'codecs.register': in two places there is such a text: `These have to be factory functions providing the following interface: factory([...] errors='strict')` -- `errors='strict'` may be confusing (at the first sight it may suggest that the only valid value is 'strict'; maybe `factory(errors=)` with an appropriate description below would be better?). 3. Ad `codecs.open`: I believe there should be a reference to the built-in open() as an alternative that is better is most cases. 4. Ad `codecs.BOM*`: `These constants define various encodings of the Unicode byte order mark (BOM).` -- the world `encodings` seems to be confusing here; maybe `These constants define various byte sequences being Unicode byte order marks (BOMs) for several encodings. They are used...` would be better? 5. Ad `7.2.1. Codec Base Classes` + `codecs.IncrementalEncoder`/`codecs/IncrementalDecoder`: * `Each codec has to define four interfaces to make it usable as codec in Python: stateless encoder, stateless decoder, stream reader and stream writer` -- only four? Not six? What about incremental encoder/decoder??? * Comparing the fragments (and tables) about error halding methods (Codecs Base Classes, IncrementalEncoder, IncrementalDecoder) with similar fragment in the `codecs.register` description and with the `codecs.register_error` description I was confused: is it the matter of a particular codec implementation or of a registered error handler to implement a particular way of error handling? I believe it would be worth to describe clearly relations between these elements of the API. Also more detailed description of differences beetween error handling for encoding and decoding, and translation would be a good thing. 6. Ad `7.2.1.6. StreamReaderWriter Objects` and `7.2.1.7. StreamRecoder Objects`: It would be worth to say explicitly that, contrary to previously described abstract classes (IncrementalEncoder/Decoder, StreamReader/Writer), these classes are *concrete* ones (if I understand it correctly). 7. Ad `7.2.4. Python Specific Encodings`: * `raw_unicode_encoding` -- see: ticket #19539. * `unicode_encoding` -- `Produce a string that is suitable as Unicode literal in Python source code` but it is *not* a string; it's a *bytes* object (which could be used in source code using an `ascii`-compatibile encoding). * `bytes-to-bytes` and `str-to-str` encodings -- maybe it would be nice to mention that these encodings cannot be used with str.encode()/bytes.decode() methods (and to mention again they *can* be used with the functions/method provided by the `codecs` module). -- assignee: docs@python components: Documentation messages: 202593 nosy: docs@python, zuo priority: normal severity: normal status: open title: 'codecs' module docs improvements versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue19548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19548] 'codecs' module docs improvements
Jan Kaliszewski added the comment: s/world/word s/begginers/beginners (sorry, it's late night here) -- ___ Python tracker <http://bugs.python.org/issue19548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19548] 'codecs' module docs improvements
Jan Kaliszewski added the comment: 8. Again ad `codecs.open`: the default file mode is actually 'rb', not 'r'. 9. Several places in the docs -- ad: `codecs.register_error`, `codecs.open`, `codecs.EncodedFile`, `Codec.encode/decode`, `codecs.StreamWriter/StreamReader` -- do not cover cases of using bytes-to-bytes and/or str-to-str encodings (especially when using `string`/`bytes` and `text`/`binary` terms). 10. `codecs.replace_errors` -- `bytestring` should be replaced with `bytes-like object` (as in other places). -- ___ Python tracker <http://bugs.python.org/issue19548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19548] 'codecs' module docs improvements
Jan Kaliszewski added the comment: 11. Ad encoding 'undefined': The sentence `Can be used as the system encoding if no automatic coercion between byte and Unicode strings is desired.` was suitable for Python 2.x, but not for Python 3.x'. I believe, this sentence should be removed. -- ___ Python tracker <http://bugs.python.org/issue19548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19548] 'codecs' module docs improvements
Changes by Jan Kaliszewski : -- versions: -Python 2.6, Python 2.7, Python 3.1 ___ Python tracker <http://bugs.python.org/issue19548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20751] Misleading examples indDescriptor protocol documentation
New submission from Jan Kaliszewski:
1. One misleading detail in the descriptor protocol documentation for super
bindings is that the following fragment of the
http://docs.python.org/reference/datamodel.html#invoking-descriptors page:
"""
Super Binding
If a is an instance of super, then the binding super(B, obj).m() searches
obj.__class__.__mro__ for the base class A immediately preceding B and then
invokes the descriptor with the call: A.__dict__['m'].__get__(obj,
obj.__class__).
"""
...introduces the method *call* (".m()") which AFAIK has nothing to do with the
actual matter of the description (attribute resolution).
Also, the "If *a* is an instance of super" fragment is strange, as *a* is not
used in the following sentences at all.
I believe the description should be:
"""
Super Binding
If binding to a super instance, super(B, obj).x searches
obj.__class__.__mro__ for the base class A immediately preceding B and then
invokes the descriptor with the call: A.__dict__['x'].__get__(obj,
obj.__class__).
"""
(using 'x' as the attribute name, as for the other kinds of binding).
***
2. Also, in some earlier fragment of the same page:
"""
Direct Call
The simplest and least common call is when user code directly invokes a
descriptor method: x.__get__(a).
"""
The call x.__get__(a) without the second argument seems to be wrong if __get__
is implemented according to the specification "object.__get__(self, instance,
owner)" from the same documentation page.
--
assignee: docs@python
components: Documentation
messages: 212035
nosy: docs@python, zuo
priority: normal
severity: normal
status: open
title: Misleading examples indDescriptor protocol documentation
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue20751>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20751] Misleading examples in the descriptor protocol documentation
Changes by Jan Kaliszewski : -- title: Misleading examples indDescriptor protocol documentation -> Misleading examples in the descriptor protocol documentation ___ Python tracker <http://bugs.python.org/issue20751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6575] Can't download docs
New submission from Jan Kaliszewski : http://docs.python.org/3.1/download.html (available both with 'Download these documents' link @docs and 'Download Current Python 3.1 Documentation' link @http://www.python.org/doc/) doesn't contain links to packed docs, but text for dev-releases: "We don't package the documentation for development releases for download. Downloads will be available for the final release." -- assignee: georg.brandl components: Documentation messages: 90937 nosy: georg.brandl, zuo severity: normal status: open title: Can't download docs type: behavior versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue6575> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6576] re docs: wrong link targets
New submission from Jan Kaliszewski : Some of links in re docs should lead to RegexObject.match()| RegexObject.search() method but lead to re.match()|re.search() module function. These are the places in 2.6 docs (in 2.7-3.2 versions' you'll find the bug in analogous places): http://docs.python.org/library/re.html#re.compile http://docs.python.org/library/re.html#re.RegexObject.match http://docs.python.org/library/re.html#re.RegexObject.search http://docs.python.org/library/re.html#re.MatchObject.pos http://docs.python.org/library/re.html#re.MatchObject.endpos http://docs.python.org/library/re.html#re.MatchObject.re http://docs.python.org/library/re.html#re.MatchObject.string (<- here maybe both possibilities should be noted, which would mean changing not only link targets but also the content) -- assignee: georg.brandl components: Documentation messages: 90941 nosy: georg.brandl, zuo severity: normal status: open title: re docs: wrong link targets versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue6576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6577] Links wrongly targeting to builtin functions' instead of module functions/methods
New submission from Jan Kaliszewski : The problem can be found in many places in docs -- tipically, where there is a function/method with name identical to builtin name (or sometimes to another function/method within the same module -- see: #6575): links leads to te latter but should lead to the former. One example -- open(): http://docs.python.org/library/shelve.html? highlight=open#shelve.DbfilenameShelf http://docs.python.org/library/shelve.html?highlight=open#example http://docs.python.org/library/sunau.html?highlight=open#sunau.openfp http://docs.python.org/library/sunau.html?highlight=open#au-read-objects http://docs.python.org/library/sunau.html?highlight=open#au-write- objects http://docs.python.org/library/wave.html?highlight=open#wave.openfp http://docs.python.org/library/wave.html?highlight=open#wave-read- objects http://docs.python.org/library/wave.html?highlight=open#wave-write- objects http://docs.python.org/library/io.html?highlight=open#module-interface http://docs.python.org/library/io.html?highlight=open#io.open http://docs.python.org/library/io.html?highlight=open#io.IOBase.readline It's hard to find all such place by hand; probably it's a job for a script... -- assignee: georg.brandl components: Documentation messages: 90943 nosy: georg.brandl, zuo severity: normal status: open title: Links wrongly targeting to builtin functions' instead of module functions/methods versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue6577> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6578] 2 problems with 'Docs for other versions' section on left HTML docs sidebar
New submission from Jan Kaliszewski : * In 2.6 the content of that section isn't up to date (3.1 is descripted as 'in development') * In 3.0 there is no that section. -- messages: 90945 nosy: zuo severity: normal status: open title: 2 problems with 'Docs for other versions' section on left HTML docs sidebar versions: Python 2.6, Python 3.0 ___ Python tracker <http://bugs.python.org/issue6578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6578] 2 problems with 'Docs for other versions' section on left HTML docs sidebar
Changes by Jan Kaliszewski : -- assignee: -> georg.brandl components: +Documentation nosy: +georg.brandl ___ Python tracker <http://bugs.python.org/issue6578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6579] No update about automatic numbering of fields in format strings (e.g. 'A {} with {} buttocks')
New submission from Jan Kaliszewski :
As we can read in http://docs.python.org/3.1/whatsnew/3.1.html#other-
language-changes:
The fields in format() strings can now be automatically numbered:
>>> 'Sir {} of {}'.format('Gallahad', 'Camelot')
'Sir Gallahad of Camelot'
Formerly, the string would have required numbered fields such as: 'Sir
{0} of {1}'.
(Contributed by Eric Smith; issue 5237.)
But it is not mentioned in 3.2's, 3.1's and 2.7's docs about format
string syntax, e.g. in 3.1 docs we have:
http://docs.python.org/3.1/library/string.html#format-string-syntax
[Please note that also grammar for a replacement field should be
updated there ('field_name' should be in '[' ']', but I'm not sure if
it'd be enough)].
--
assignee: georg.brandl
components: Documentation
messages: 90946
nosy: georg.brandl, zuo
severity: normal
status: open
title: No update about automatic numbering of fields in format strings (e.g. 'A
{} with {} buttocks')
versions: Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue6579>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4947] sys.stdout fails to use default encoding as advertised
Jan Kaliszewski added the comment: The matter had been discussed (and not once...), IMO without satisfactory conclusion -- see: * http://bugs.python.org/issue612627 (the feature added) * http://bugs.python.org/issue1214889 (another feature rejected) * http://bugs.python.org/issue1099364 (problems reported) * http://bugs.python.org/issue967986 (problems reported) * http://mail.python.org/pipermail/python-list/2008-December/693601.html * http://mail.python.org/pipermail/python-dev/2008-December/084362.html * and probably in many other places... Anyway, it's definitely a bug -- either in the language/implementation or in the documentation. -- nosy: +zuo ___ Python tracker <http://bugs.python.org/issue4947> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4947] sys.stdout fails to use default encoding as advertised
Jan Kaliszewski added the comment: PS. The main problem is not a lack of feature but that inconsistency, and that's not documented if File type docs: print >>my_file, my_unicode # <- is encoded with my_file.encoding my_file.write(my_unicode) # <- is encoded with my_file.encoding # and on the other hand: print my_unicode -- works # <- is encoded with my_file.encoding sys.stdout.write(my_unicode) # <- is encoded with what is returned by sys.getdefaultencoding() -- versions: +Python 2.4 ___ Python tracker <http://bugs.python.org/issue4947> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4947] sys.stdout fails to use default encoding as advertised
Jan Kaliszewski added the comment: s / if File / in File s / -- works # <- is encoded with my_file.encoding / # <- is encoded with sys.stdout.encoding (sorry, too little sleep) -- ___ Python tracker <http://bugs.python.org/issue4947> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4947] sys.stdout fails to use default encoding as advertised
Changes by Jan Kaliszewski : -- assignee: -> georg.brandl components: +Documentation nosy: +georg.brandl ___ Python tracker <http://bugs.python.org/issue4947> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19539] The 'raw_unicode_escape' codec buggy + not appropriate for Python 3.x
Changes by Jan Kaliszewski : -- resolution: -> duplicate status: open -> closed ___ Python tracker <http://bugs.python.org/issue19539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19539] The 'raw_unicode_escape' codec buggy + not appropriate for Python 3.x
Jan Kaliszewski added the comment: My concerns are now being addressed in the issue19548. -- ___ Python tracker <http://bugs.python.org/issue19539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23232] 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones
New submission from Jan Kaliszewski: To some extent, this issue is a follow-up of Issue 20132. It concerns some parts of functionality + documentation of the 'codecs' module related to registering custom codecs, especially non-string ones (i.e., codecs that encode/decode between arbitrary types, not necessarily the str and bytes types). A few fragments of documented behaviour and/or documentation itself bother me: 0. Ad "7.2.1. Codec Base Classes" "Each codec has to define four interfaces to make it usable as codec in Python: stateless encoder, stateless decoder, stream reader and stream writer. The stream reader and writers typically reuse the stateless encoder/decoder to implement the file protocols. Codec authors also need to define how the codec will handle encoding and decoding errors." IMHO it is still unclear: a) what is the relation between codecs in this meaning and CodecInfo objects? (especially: CodecInfo contains information about six interfaces, not four) b) How codec authors define "how the codec will handle encoding and decoding errors"? What is relation between this and error handling schemes (defined as generic, not per-codec ones) documented below? 1. Ad "7.2.1.1. Error Handlers" and "codecs.strict_errors(exception)" "'strict' Raise UnicodeError (or a subclass); this is the default. Implemented in strict_errors()." "codecs.strict_errors(exception) Implements the 'strict' error handling: each encoding or decoding error raises a UnicodeError." Is it true that always it is a UnicodeError or its subclass and not just ValueError or its subclass? (as it is described in other fragments of the module documentation). Please note, that 'strict' is documented as a universal (and not e.g. text-encoding-only) error handling scheme. So, what about non-string codecs? 2. Ad "codecs.register_error(name, error_handler)" "For encoding, error_handler will be called with a UnicodeEncodeError instance..." "Decoding and translating works similarly, except UnicodeDecodeError or UnicodeTranslateError will be passed..." Again: what about non-string codecs? UnicodeError subclasses do not seem to be appropriate for them. 3. It would be nice to address the Zoinkity's concerns from the Issue 20132 (partially related to the above points): """ One glaring omission is any information about multibyte codecs--the class, its methods, and how to even define one. Also, the primary use for codecs.register would be to append a single codec to the lookup registry. Simple usage of the method only provides lookup for the provided codecs and will not include regularly-accessible ones such as "utf-8". It would be enormously helpful to provide an example of proper, safe usage. """ -- assignee: docs@python components: Documentation, Library (Lib) messages: 233940 nosy: docs@python, zuo priority: normal severity: normal status: open title: 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones versions: Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue23232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23232] 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones
Jan Kaliszewski added the comment: Sorry, s/Issue 20132/Issue 19548/g Issue 20132 is also related somehow, but here I ment that this is a follow-up of Issue 19548; and Zoinkity's concerns I cited are also from Issue 19548, and not from 20132. -- ___ Python tracker <http://bugs.python.org/issue23232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
