[Python-ideas] More alternate constructors for builtin type

Christopher Barker pythonchb at gmail.com
Tue May 7 01:41:21 EDT 2019


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") ?

I know my newbie students wouldn't like that.

The one exception to all this in my mind is bytes -- which has come up the
most in this discussion. But that's not because the bytes constructor is
overloaded but rather that the bytes object is overloaded: is is storage
for binary data, which its name seems to imply? or is an old-style text
type?

It's probably too late to do anything about that, but if we do want to
"clean up" something, that would be it.

"""
str(n) that cannot be translated to bytes(n) but must instead be written as
b"%d" % n,
"""

if bytes were really well, bytes, then that would be:

bytes((ord(c) for c in str(n)))

or

str(n).encode('ascii')


ugly, I know. I kinda wish we'd simply kept a single_byte_string object
(essentially a py2 string) as its own thing, separate from a bytes object,
which could then keep its nominal meaning -- a sequence of individual
arbitrary bytes.

Oh well, lots of water under that bridge.....

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190506/3a9397d1/attachment.html>


More information about the Python-ideas mailing list