Too much builtins (was Re: Python's simplicity philosophy

[Andrew Dalke]

Georgy Pruss:
> Just wanted to get rid of some useless builtin functions and make the
> language prettier.

But I don't think that functions with special cases (and the special
case of 'takes a base but only if the first arg is an integer) is pretty.
As I've mentioned, I've not problems if hex/oct are moved to some
module in some future version of Python.

> BTW is there some Python's equivalents to C's strspn, strcspn, strpbrk,
> which return a leading sub-string, entirely [not] consisting of characters
> of some char.set; and something like strtoul which parses the string and
> returns the number and the position where the scan ended?

Not directly.  In Python those are most often done with regexps.
Eg,

import re
def strspn(s, t):
  # kinda slow way to construct the pattern, but it does correctly
  # handle the '-' and ']' cases.  Usually one would write the regexp
  # directly and not try to get close to the C API.
  pat = re.compile("(" + "|".join(map(re.escape, t) + ")*")
  m = pat.match(s)
  if not m:
    return 0
  return m.end()


> Fortunatelly, str() here is a bit wiser than repr().
> >>> str(float("1.1")) == "1.1"
> True

Wiser?  Or more approximate?  IEE 754 math cannot explicitly
store the value "1.1".

>>> str(1.1000000000000001)
'1.1'
>>>

> Regarding the complex numbers, I guess the inconsistency with them
> is to some extent the consequence of the fact that Python has no
> complex literals (contrary to e.g. J) and the str(cmplx) returns some
> expression in parenthesis instead of one complex number. So this
> case is the same as with lists and other compound objects.

In some sense you are correct.  Python doesn't have a complex
literal -- it only has an imaginary literal, so '1+2j' is implemented as

              0 LOAD_CONST               1 (1)
              3 LOAD_CONST               2 (2j)
              6 BINARY_ADD

So I'll change my statement and point out that

str(complex("3j")) == "3j"

(note the lack of parens) so the same symmetry you argue for
str/int should work for str/complex (though complex assumes
floats for the real and imaginary values, so it's more akin to the
str/float relationship.)

                    Andrew
                    dalke at dalkescientific.com