Chris Angelico writes:
> On Wed, Mar 26, 2014 at 11:54 AM, Nikolaus Rath wrote:
>> 2. Change the behavior immediately, potentially breaking some
>>applications that worked around it, but unbreaking others that relied
>>on the documented behavior.
>
> If it's a functionality change that's
On Wed, Mar 26, 2014 at 11:54 AM, Nikolaus Rath wrote:
> 2. Change the behavior immediately, potentially breaking some
>applications that worked around it, but unbreaking others that relied
>on the documented behavior.
If it's a functionality change that's likely to break code, would it
b
Hello,
I'd like to hear some more opinions on
http://bugs.python.org/issue20951. I think the possible courses of
action are:
1. Document the current behavior.
This has the drawback that (a) it still remains rather
counterintuitive, and (b) one still needs extra code to distinguish
betwe
