list(), tuple() should not place at "Built-in functions" in documentation

[Stefan Behnel]

Terry Reedy, 15.07.2011 05:00:
> On 7/14/2011 9:51 PM, Ben Finney wrote:
>> Steven D'Aprano writes:
>>
>>> Inside wrote:
>>>
>>>> As telling in the subject,because "list" and "tuple" aren't functions,they
>>>> are types.Is that right?
>
> At one time (before 2.2), they were functions and not classes.

They are still functions in the sense that you can call them (with or 
without arguments) and get a result back. The exact distinction can be 
considered an implementation detail in most contexts.

There are even extreme cases that render the distinction completely 
useless. Think of type(), for example. In its exceedingly most common use 
case, it does *not* create a type, even if it's a call to a type 
constructor. Something similar applies to a no-args call to tuple(), which 
does not create a new object in CPython, but only returns a new reference 
to a singleton.

Types in Python are allowed to do these things, so it's not always 
meaningful to distinguish between typeX() being a call to a type or a function.


>>> Yes they are types. But they can still be used as functions. Does it
>>> matter?
>>
>> As a newcomer to the documentation I looked fruitlessly in the table of
>> contents for a section that would contain the built-in types. “Built-in
>> functions” was eliminated for the reason the OP states.
>>
>> I think it matters. (But I haven't proposed a documentation patch for it.)
>
> I once proposed, I believe on the tracker, that 'built-in functions' be
> expanded to 'built-in function and classes'. That was rejected on the basis
> that people would then expect the full class documentation that is in the
> 'built-in types' section (which could now be called the built-isssn classes
> section.
>
> A more exact title would be 'built-in callables', but that would be even
> less helpful to newcomers. Callables are functions in the generic sense.

I think "function" is about the best "expected" and "newcomer-friendly" 
name one can give to a "callable", especially in the context of a 
duck-typed, protocol-oriented language like Python. The section title in 
question describes perfectly its contents.

It's a different question if a separate section like "here's a list of 
reference to the descriptions of types that Python provides in its 
builtins" is required. But I think we have that already.


> In any case, the new index makes it easy to see what is in that chapter.

Agreed.

Stefan