list(), tuple() should not place at "Built-in functions" in documentation
stefan_ml at behnel.de
Fri Jul 15 23:03:18 CEST 2011
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
>> 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
> 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.
More information about the Python-list