Initializing a list with copies

[Steve Holden]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:LJDz8.35771$8D3.1034180 at news1.tin.it...
> Steve Holden wrote:
>         ...
> > sloppiness. And, of course, to confound the confusion int() is *not* a
> > call to the integer class/type creator, but a no-argument call of the
> > built-in int() function. What happens to "int(x[, radix]) " when int is
a
> > built-in type, by the way, or isn't that going to happen?
>
> Steve, what are you _taking_ about...?
>
> >>> type(int)
> <type 'type'>
> >>> int('23',6)
> 15
>
> int *is* a built-in type, a call to it is a call to the int type, and one
of
> the ways you can call the int type to create an int istance is with a
> string argument and optionally a radix integer argument.
>
> Are you stuck in the far, dark ages of Python 2.1 ... ?-)

[...]

Well, I was only quoting the 2.2 Python Library Reference (section 2.1,
ironically enough) [he said, mildly]:

"""
int(x[, radix])
Convert a string or number to a plain integer. If the argument is a string,
it must contain a possibly signed decimal number representable as a Python
integer, possibly embedded in whitespace; this behaves identical to
string.atoi(x[, radix]). The radix parameter gives the base for the
conversion and may be any integer in the range [2, 36], or zero. If radix is
zero, the proper radix is guessed based on the contents of string; the
interpretation is the same as for integer literals. If radix is specified
and x is not a string, TypeError is raised. Otherwise, the argument may be a
plain or long integer or a floating point number. Conversion of floating
point numbers to integers truncates (towards zero).
"""

So, while I thought the change had been made (because type(int) ==
type(type)) the documentation seemed to say otherwise. This is the kind of
situation that tends to confuse. Even though the type/class unification is
going ahead, the documentation isn't explicit about it, and int() is still
represented as a built-in function when really it's a type. Unless, that is,
you know different.

Types, of course, are callables, so it's reasonable to represent them as
functions, but it's interesting that the new types' constructors are so
explicitly polymorphic across the "sensible" arguments. The documentation is
unchanged in the CVS tree.

regards
 Steve
--

Steve Holden: http://www.holdenweb.com/ ; Python Web Programming:
http://pydish.holdenweb.com/pwp/