On 2020-04-30 1:07 p.m., Ethan Furman wrote:
On 04/30/2020 07:58 AM, Christopher Barker wrote:
On 04/29/2020 10:51 PM, Stephen J. Turnbull wrote:
I think that the issue of searchability and signature are pretty
compelling reasons for such a simple feature to be part of the
function name.
On 1/05/20 2:58 am, Christopher Barker wrote:
Imagine someone that uses zip() in code that works for a while, and then
discovers a bug triggered by unequal length inputs.
If it’s a flag, they look at the zip docstring, and find the flag, and
their problem is solved.
Why would they look at
On Apr 30, 2020, at 07:58, Christopher Barker wrote:
>
>> I think that the issue of searchability and signature are pretty
>> compelling reasons for such a simple feature to be part of the
>> function name.
>
> I would absolutely agree with that if all three function were in the same
>
On Apr 29, 2020, at 22:50, Stephen J. Turnbull
wrote:
> Andrew Barnert via Python-ideas writes:
>
>>> Also -1 on the flag.
>
> Also -1 on the flag, for the same set of reasons.
>
> I have to dissent somewhat from one of the complaints, though:
>
>> auto-complete won’t help at all,
Thanks
On 04/30/2020 07:58 AM, Christopher Barker wrote:
On 04/29/2020 10:51 PM, Stephen J. Turnbull wrote:
I think that the issue of searchability and signature are pretty
compelling reasons for such a simple feature to be part of the
function name.
I would absolutely agree with that if all three
> I think that the issue of searchability and signature are pretty
> compelling reasons for such a simple feature to be part of the
> function name.
I would absolutely agree with that if all three function were in the same
namespace (like the string methods referred to earlier), but in this
Andrew Barnert via Python-ideas writes:
> > Also -1 on the flag.
Also -1 on the flag, for the same set of reasons.
I have to dissent somewhat from one of the complaints, though:
> auto-complete won’t help at all,
Many (most?) people use IDEs that will catch up more or less quickly,
though.
