[Python-ideas] More alternate constructors for builtin type

[Oscar Benjamin]

On Tue, 7 May 2019 at 06:42, Christopher Barker <pythonchb at gmail.com> wrote:
>
> Oddly, it seems everyone in this thread thinks it would be "Better" to have a bunch of constructors, ratehr than the overloading, of only we didn't have backward compatibility to worry about.
>
> I disagree -- these efficiencies are what I LIKE about python:
>
> int() tries to turn whatever you pass into into an integer -- a float, a string, whatever. Do people really think that it would be better if we all had to write:
>
> int.parse("123")
>
> Rather than just int("123") ?

It depends whether you want to have an exception if the wrong type of
input is encountered. The alternative to x=int.parse(s) might instead
be

    if not isinstance(s, str):
        raise TypeError('need a string')
    x = int(s)

One of the things I like about Python compared to e.g. C is that it
often tells me when something is going wrong in some code rather than
silently doing the wrong thing.

The int function accepts all kinds of things e.g.

    >>> int('๒')
    2

However in my own code if that character ever got passed to int then
it would definitely indicate either a bug in the code or data
corruption so I'd rather have an exception.

Admittedly the non-ASCII unicode digit example is not one that has
actually caused me a problem but what I have had a problem with is
floats. Given that a user of my code can pass in a float in place of a
string the fact that int(1.5) gives 1 can lead to bugs or confusion.
For precisely these reasons there is the __index__ method to get
around this for the situations where you want to convert a non-int
integer type to int (without accepting strings or floats). There is
math.trunc for the situation where you are not parsing strings and
actually do want to accept non-integer numbers and truncate them.
There is no function to parse a decimal integer string without also
accepting floats though.

--
Oscar