Why date do not construct from date?

[Lie Ryan]

Lie Ryan wrote:
> Gabriel Genellina wrote:
>> En Tue, 02 Jun 2009 03:14:22 -0300, Chris Rebert <clp2 at rebertia.com>
>> escribió:
>>
>>> On Mon, Jun 1, 2009 at 10:25 PM, Alexandr N Zamaraev
>>> <tonal at promsoft.ru> wrote:
>>>>>>> import datetime as dt
>>>>>>> d = dt.date(2009, 10, 15)
>>>>>>> dt.date(d)
>>>> Traceback (most recent call last):
>>>>  File "<stdin>", line 1, in <module>
>>>> TypeError: function takes exactly 3 arguments (1 given)
>>>> Why int form int, str from str, Decumal from Decumal can construct
>>>> bat date from date not?
>>> Probably because the function signatures would be so different. str(),
>>> int(), etc *always* take *exactly one* argument -- the object to
>>> convert. In contrast, date() takes several integers corresponding to
>>> the year, month, and day. Adding a second signature to it that took
>>> exactly one argument (of type `date`) and copied it would be
>>> significantly different from its other signature; in idiomatic Python,
>>> one would typically make a separate, new function for this drastically
>>> different signature.
>> That doesn't convince me. It's not very consistent along the various
>> types: int("3ab0",16) is rather different than int(3.2) but they're the
>> same function...
> 
> Strictly speaking int("3ab0",16) does not create an int from an int,
> instead it creates an int from a string.
> 
> Maybe you want to say int(3) -> 3 ?
> 
>>> However, the `date` type is immutable, so there's no reason at all to
>>> try and copy a new instance from an existing one anyway, thus a
>>> single-argument copy-constructor is completely unnecessary, hence why
>>> there isn't one.
>> Isn't the same for all other examples (int, float, str, Decimal...)?
>> They're all immutable types, and some have several and rather different
>> constructor signatures:
> 
> int(ob), float(ob), and str(ob) are type casting (strictly speaking it
> is not a type casting, but you get the idea); while date() is a
> constructor for the date object. Strictly speaking int(ob), float(ob),
> and str(ob) merely calls the special ob.__int__, ob.__float__, and
> ob.__str__. These special functions are there to convert the current
> object into int, float, or str wherever defined. It just happens that
> calling int.__int__, float.__float__, and str.__str__ just returns
> themselves.
> 
> For Decimal, (I think) it is as a symmetry to float since Decimal is
> intended to be used whenever IEEE 764 behavior does not suit you.

In fact, the doc of int and float says "Convert a string or number to an
integer, if possible" and "Convert a string or number to a floating
point number, if possible" respectively. There is no mention that they
are constructors at all...

While the doc for str says "Return a nice string representation of the
object." the argument still holds since the "nice string representation"
for a string is the string itself...

Decimal is the rotten apple here since it just mimics float(). But that
is why Decimal is in separate module and there is no decimal() built-in.
Classes in modules are free to do anything they want to do... including
mimicking float() or deciding not to accept its own self as a valid
initializer.