[Python-ideas] Integrate some itertools into the Python syntax

[Andrew Barnert]

On Mar 23, 2016, at 16:00, Chris Angelico <rosuav at gmail.com> wrote:
> 
>> On Thu, Mar 24, 2016 at 9:38 AM, Andrew Barnert <abarnert at yahoo.com> wrote:
>>> On Mar 23, 2016, at 15:01, Chris Angelico <rosuav at gmail.com> wrote:
>>> 
>>>> On Thu, Mar 24, 2016 at 8:46 AM, Andrew Barnert <abarnert at yahoo.com> wrote:
>>>> The advantage of having a small set of builtins is that you know the entire
>>>> set of builtins.
>>> 
>>> Python 3.6 has len(dir(builtins))==150, which is hardly small. Even
>>> removing the ones that don't begin with a lower-case letter (which
>>> removes a small number of special names like __package__, and a large
>>> number of exception classes) leaves 72. Can you name them all?
>> 
>> Can you name all 25000 words of English that you know?
>> 
>> There are 68 builtins listed in a nice table at the top of the builtin functions chapter in the docs. Take a look at that table. They're all (except maybe format and iter[1]) functions[2] that you can immediately recognize them when reading them, and recall when they're relevant to code you're writing, including know exactly what their interface is and what they do. If you see "any()" or "int()" in code, you don't need to turn to the docs to look up what it does. If you need to convert something to a debug string representation, you know to call "repr()". The fact that you might leave out "any", "int", or "repr" in a pop quiz demanding that you list all 68 of them in alphabetical order doesn't mean you don't know them.
>> 
>> You certainly can't say the same is true for all functions and methods in the stdlib.
> 
> Fair enough, naming them all is a poor definition of "know". But the
> flip side (knowing what one means when you meet it) is also a poor
> definition. The real trick is knowing, when you're faced with a
> problem, what the solution is;

Well, readability is at least as important as writability. But yes, writability is also important, which is why I covered it: 'If you need to convert something to a debug string representation, you know to call "repr()".'

> and while most people here will be able
> to do that, I'm not sure that every Python programmer can.

Sure, there's a certain level of competence below which you can't say people know all the builtins. There's also a certain level of competence below which you can't say people know every kind of statement in the syntax. But the point is that the level is low enough to be reasonably achievable. It's not only the hardcore experts that know almost all of the builtins. If we tripled the number of builtins, I don't think that would be true anymore.

(Secondarily, the alphabetical chart in the docs is good enough at 68; at 200, we'd almost certainly need to reorganize it to make it useful.)

> Some
> builtins are well known, like int and len; others, not so much - zip,
> hash, divmod. And then there are some (compile, bytearray, callable)
> that, if they were elsewhere in the stdlib, would barely change
> people's code.

I don't think anyone would be horribly bothered by moving compile outside of builtins, but it has to be there for bootstrapping reasons. (Maybe that isn't true anymore, but it apparently was in 3.0.)

For callable, that actually _was_ removed from builtins in 3.0, and added back pretty late in the 3.2 cycle because, as it turns out, people really did miss it more than you'd expect a priori.

But anyway, the presence of 2 or 3 or even 10 functions out of those 68 that maybe shouldn't be there isn't license to add 100 more. If anything, it means we have to be a tiny bit more careful what we add there in the future.

> My conclusion: itertools.chain is just as discoverable as
> builtins.chain, so the only real benefit would be playing around at
> the interactive prompt, which you can improve on with an auto script.
> -0.5 on making chain a builtin.

I don't think it's _just_ as discoverable. But I do think it's discoverable _enough_. (Plus, as I already mentioned, I think chain.from_iterable is more of a problem than chain, and moving chain to builtins wouldn't help that problem enough to be worth doing.) So I'm also -0.5.