[issue20496] function definition tutorial encourages bad practice
New submission from Alan Isaac: Section 4.6 of the tutorial introduces function definition: http://docs.python.org/3/tutorial/controlflow.html#defining-functions The first example defines a function that *prints* a Fibonacci series. A basic mistake made by students new to programming is to use a function to print values rather than to return them. In this sense, the example encourages bad practice and misses an opportunity to instruct. Since they have already met lists in Section 3, I suggest that returning a list of the values and then printing the list would enhance the tutorial. -- assignee: docs@python components: Documentation messages: 210077 nosy: aisaac, docs@python priority: normal severity: normal status: open title: function definition tutorial encourages bad practice type: enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
New submission from Alan Isaac: The need for weighted random choices is so common that it is addressed as a common task in the docs: http://docs.python.org/dev/library/random.html This enhancement request is to add an optional argument to random.choice, which must be a sequence of non-negative numbers (the weights) having the same length as the main argument. -- messages: 196229 nosy: aisaac priority: normal severity: normal status: open title: allow weights in random.choice type: enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11023] pep 227 missing text
Alan Isaac alan.is...@gmail.com added the comment: Bear with my confusion about your response. Are you saying that CPython documentation bugs cannot be submitted here, or that this does not constitute a CPython documentation bug? I assume the latter. But then, can you tell me where to find the correct CPython documentation after I read the following quote from PEP 277? http://www.python.org/dev/peps/pep-0227/ Implementation XXX Jeremy, is this still the case? The implementation for C Python uses flat closures [1]. In case you might care about a user confusion ... Your reply left me puzzled that PEPs that have reached the standards track would not be considered part of the CPython documentation distribution. Thank you, Alan Isaac -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11023 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11023] pep 227 missing text
New submission from Alan Isaac alan.is...@gmail.com: In PEP 227 missing text is marked with XXX. Most of this is just calls for examples and elaboration. However under the Implementation section XXX marks a substantive question about the documentation. Fixing this may be low priority, but a tracker search suggested it is currently not even being tracked ... -- assignee: docs@python components: Documentation messages: 127184 nosy: aisaac, docs@python priority: normal severity: normal status: open title: pep 227 missing text type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11023 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5716] Overzealous deprecation of BaseException.message
Alan Isaac alan.is...@gmail.com added the comment: FYI a patch has been committed that should fix this. For discussion see http://bugs.python.org/issue6844 -- nosy: +aisaac ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6844] BaseException DeprecationError raises inappropriately
Alan Isaac alan.is...@gmail.com added the comment: I hope it is not too annoying to link these ... I asked thhis of Jean-Paul but now I'll ask it of George. Since you are working on this, can you see if http://bugs.python.org/issue6108 is related or in any case can be fixed at the same time? Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6844] BaseException DeprecationError raises inappropriately
Alan Isaac alan.is...@gmail.com added the comment: Since you are working on this, can you see if http://bugs.python.org/issue6108 is related or in any case can be fixed at the same time? Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6844] BaseException DeprecationError raises inappropriately
Alan Isaac alan.is...@gmail.com added the comment: The 'message' attribute itself is deprecated as it didn't exist prior to being introduced in 2.5. That seems to me to be the wrong way to phrase it, and indeed that kind of phrasing implies the current bug. For example, it leads to the incorrect statement that The 'message' attribute ... didn't exist prior to being introduced in 2.5. But looking at the docutils and Twisted code bases, to take two examples, tells us that it **did** exist: a slew of instances had this attribute. The correct statement, that BaseException did not initialize a `message` attribute, is an entirely different matter. Imo, deprecating setting and accessing an **instance attribute** is just flat out wrong and grossly violates inheritability promises. As we have seen. I think (?) that what was desired to be deprecated is the combination of - setting a message attribute via BaseException.__init__, AND - accessing an instances message attribute that was set *this way* But in fact the setting cannot really be deprecated because it is implicit: it is something currently done by BaseException, not by the user. So I think (?) the best we can do is look at whether the user initializes BaseException (**not** the derived classes) with a single argument, which is a nonempty string, and then tries to access this as a `message` attribute. Which is why I originally proposed setting a flag when BaseException.__init__ is called and conditioning the deprecation warning on this flag. (E.g., the flag could be set if and only if the user calls BaseException.__init__(instance, string).) In any case, I think Jean-Paul is asking exactly the right question (i.e., just what exactly is being deprecated?). A more careful answer will hopefully lead to less buggy DeprecationWarning. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6844] BaseException DeprecationError raises inappropriately
New submission from Alan Isaac alan.is...@gmail.com: In Python 2.6 if I subclass Exception and intialize my instances with a `message` attribute, I get a DeprecationError via BaseException. Of course there is no problem in Py3, because adding a `message` attribute to instances of a subclass is in fact **not** a problem and will **not** be disallowed. I.e., the DeprecationError is raised incorrectly in Python 2.6. I am not sure how to raise a DeprecationError *only* in the correct cases, but certainly the current behavior can be much improved. As a crude example, if the `args` passed to BaseException has length 0, then a flag could be set not to raise this DeprecationError. Even if not perfect, this would be **much** better than the current behavior, since it is common practice not to pass the subclass's initialization arguments on to Exception.__init__. This behavior can be expected to affect entire libraries and therefore should be fixed. (Eg., it affects docutils.) I.e., change the name of your variable is the wrong answer to this bug report. -- components: Interpreter Core messages: 92281 nosy: aisaac severity: normal status: open title: BaseException DeprecationError raises inappropriately type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
