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
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
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 ``&q
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__
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
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
Changes by Jan Kaliszewski z...@chopin.edu.pl:
--
resolution: - duplicate
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19539
Jan Kaliszewski added the comment:
My concerns are now being addressed in the issue19548.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19539
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
Changes by Jan Kaliszewski z...@chopin.edu.pl:
--
title: Misleading examples indDescriptor protocol documentation - Misleading
examples in the descriptor protocol documentation
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
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
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
Jan Kaliszewski added the comment:
s/world/word
s/begginers/beginners
(sorry, it's late night here)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19548
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
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
Changes by Jan Kaliszewski z...@chopin.edu.pl:
--
versions: -Python 2.6, Python 2.7, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19548
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
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
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
Jan Kaliszewski z...@chopin.edu.pl 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 rep...@bugs.python.org
http
Jan Kaliszewski z...@chopin.edu.pl 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
Jan Kaliszewski z...@chopin.edu.pl 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
Jan Kaliszewski z...@chopin.edu.pl added the comment:
PS. Newer, shorter version: http://dpaste.org/2aiQ/
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
Changes by Jan Kaliszewski z...@chopin.edu.pl:
--
nosy: +zuo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9232
___
___
Python-bugs-list mailing
Jan Kaliszewski z...@chopin.edu.pl 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
Jan Kaliszewski z...@chopin.edu.pl added the comment:
python-dev discussion continuation:
http://mail.python.org/pipermail/python-dev/2010-December/106770.html
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9232
New submission from Jan Kaliszewski z...@chopin.edu.pl:
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
Jan Kaliszewski z...@chopin.edu.pl added the comment:
s/**{5: 6}/**{'5': 6}/g (but it's a detail)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10682
Jan Kaliszewski z...@chopin.edu.pl 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
New submission from Jan Kaliszewski z...@chopin.edu.pl:
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
Jan Kaliszewski z...@chopin.edu.pl 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
Jan Kaliszewski z...@chopin.edu.pl 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
Jan Kaliszewski z...@chopin.edu.pl 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 rep...@bugs.python.org
http
Changes by Jan Kaliszewski z...@chopin.edu.pl:
--
title: Doc for itertools recipe consume is complicated and less efficient -
dictview
versions: -Python 2.6, Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Jan Kaliszewski z...@chopin.edu.pl:
--
title: dictview - Doc for itertools recipe consume is complicated and less
efficient
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7764
Jan Kaliszewski z...@chopin.edu.pl added the comment:
(sorry! typed into a wrong field)
--
nosy: +zuo
versions: +Python 2.6, Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7764
New submission from Jan Kaliszewski z...@chopin.edu.pl:
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
New submission from Jan Kaliszewski z...@chopin.edu.pl:
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
New submission from Jan Kaliszewski z...@chopin.edu.pl:
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
New submission from Jan Kaliszewski z...@chopin.edu.pl:
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
New submission from Jan Kaliszewski z...@chopin.edu.pl:
* 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
Changes by Jan Kaliszewski z...@chopin.edu.pl:
--
assignee: - georg.brandl
components: +Documentation
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6578
New submission from Jan Kaliszewski z...@chopin.edu.pl:
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
Jan Kaliszewski z...@chopin.edu.pl 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
Jan Kaliszewski z...@chopin.edu.pl 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
Jan Kaliszewski z...@chopin.edu.pl 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 rep...@bugs.python.org
http
Changes by Jan Kaliszewski z...@chopin.edu.pl:
--
assignee: - georg.brandl
components: +Documentation
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4947
New submission from Jan Kaliszewski z...@chopin.edu.pl:
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
48 matches
Mail list logo
