Mailman 3 April 2011 - docs

[issue11796] Comprehensions in a class definition mostly cannot access class variable
by Michael Foord April 10, 2011

April 10, 2011

Changes by Michael Foord <michael(a)voidspace.org.uk>: ---------- nosy: +michael.foord _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11796> _______________________________________

1 0

[issue11796] Comprehensions in a class definition mostly cannot access class variable
by Menno Smits April 9, 2011

April 9, 2011

Menno Smits <menno(a)freshfoo.com> added the comment: Thanks to everyone for the explanations. I was hoping for behaviour along the lines of Python 2 (certainly not artificially blocking more cases in the name of consistency) but it doesn't look like that's going to happen. I think this is one slight and rare area where Python 3 has taken a step backwards when compared to Python 2 but I can live with it. As noted there's other ways to achieve the same thing. The new Python 3 behaviour … [View More]

1 0

[issue11796] Comprehensions in a class definition mostly cannot access class variable
by Terry J. Reedy April 9, 2011

April 9, 2011

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: Thanks. I remember now: the initial iter_exp is evaluated immediately because it always *can* be, because it is only evaluated once and can only involve 'outside' names, whereas the result expression and any conditional expressions and further iteration expressions cannot be (evaluated immediately) because in general they usually involve the loop_var and are evaluated many times, each time with a different value of the loop_var (… [View More]

1 0

[issue11796] Comprehensions in a class definition mostly cannot access class variable
by Raymond Hettinger April 9, 2011

April 9, 2011

Raymond Hettinger <raymond.hettinger(a)gmail.com> added the comment: > Devs are aware that there is an exception to the general rule > for the 'for' clause. There is a technical reason why the > exception is possible, though I have forgotten it. It is best understood when thinking about a gexexp that gets run long after is created: ge = (result_exp(loop_var) for loop_var in iter_exp) The idea was to have the body of the iterator expression, iter_exp, fail early, before … [View More]

1 0

[issue11796] Comprehensions in a class definition mostly cannot access class variable
by Terry J. Reedy April 9, 2011

April 9, 2011

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: Title changed. Generator expressions had the same limitation in 2.x. All comprehensions have the same limitation in 3.x. ---------- title: list and generator expressions in a class definition fail if expression condition refers to a class variable -> Comprehensions in a class definition mostly cannot access class variable _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11796> _______________________________________

1 0

[issue11796] list and generator expressions in a class definition fail if expression condition refers to a class variable
by Terry J. Reedy April 9, 2011

April 9, 2011

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: Devs are aware that there is an exception to the general rule for the 'for' clause. There is a technical reason why the exception is possible, though I have forgotten it. Since you already know that changing the general behavior has been rejected, are you asking that the exception be removed (for consistency) , so that your first example would fail? If so, that will be rejected also. I am changing this to a doc issue in case you or … [View More]

1 0

[issue11794] Backport new logging docs to 2.7
by Nick Coghlan April 8, 2011

April 8, 2011

New submission from Nick Coghlan <ncoghlan(a)gmail.com>: Vinay did some great work on the logging documentation for 3.2 (http://docs.python.org/py3k/library/logging). However, a lot of people will currently miss it, since they land on the existing 2.7 documentation (http://docs.python.org/library/logging) instead. A backport would update the web site immediately, and then be incorporated in the bundled documentation when 2.7.2 is released (presumably later this year). Backporting … [View More]

4 4

documentation bug in "C/API Unicode Objects and Codecs"
by tomo cocoa April 7, 2011

April 7, 2011

Hello I am a Japanese Pythonista and a Python documentation translator. I found a bug in the documentation of UTF-16 Codecs. http://docs.python.org/c-api/unicode.html#utf-16-codecs The passages about the function PyUnicode_DecodeUTF16 starts with "Decode length bytes from". But I think s/length/size/, because there is no formal parameter named "length" but "size". Regards -- class Cocoatomo: name = 'cocoatomo' email_address = 'cocoatomo77(a)gmail.com' &… [View More]

1 0

[issue10977] Concrete object C API needs abstract path for subclasses of builtin types
by Nick Coghlan April 7, 2011

April 7, 2011

Nick Coghlan <ncoghlan(a)gmail.com> added the comment: I thought about a warning, but the problem is that a subclass using the concrete API as part of its *implementation* of the associated slot or method is actually perfectly correct usage. I'm not sure this is enough to give up on the idea of OrderedDict being a dict subclass implemented in C, though. It seems to me that some defensive internal checks (to pick up state corruption due to this problem) would be a lesser evil than giving … [View More]

1 0

[issue10977] Concrete object C API needs abstract path for subclasses of builtin types
by Raymond Hettinger April 6, 2011

April 6, 2011

Raymond Hettinger <raymond.hettinger(a)gmail.com> added the comment: One thing that could be done is to have an optional warning in the mutating concrete C API functions that gets triggered whenever the input doesn't have an exact type match. That will let people discover incorrect uses. We could also scour our own stdlib code to see if there are any cases where there needs to be an alternate code patch for subclasses of builtin types. I did a scan for PyList_SetItem and found that we … [View More]

1 0