Comment on draft PEP for deprecating six builtins

[Bernhard Herzog]

"John Roth" <johnroth at ameritech.net> writes:

> To me, .join() makes much more sense as a list or tuple method than
> either. Semantically, .join() takes a sequence and transforms it into
> a string, therefore it should be a method on the input type (the
> sequence),
> not on the output type (the string).

IMO join takes two inputs. A sequence of strings and a delimiter (can't
think of a better word for it at the moment) and produces a string as
result. The delimiter is somewhat less important than the sequence
because it can be omitted. OTOH, the sequence argument belongs to only a
subset of sequence as it must be a sequence of strings, so join as a
method of sequences would fail for a lot of sequences. Therefore IMO join is
neither strongly a string method nor a sequence method.

> I'm against making such things global functions for a number of
> reasons, not least of which is the potential combinatorial explosion.

They don't have to be globals. The function join is in the string
module, for instance.

> > I see numbers and characters as quite different datatypes and a
> > conversion between the two is right in the middle and neither more on
> > the int side than on the str side.
> 
> True, but not very relevant.

Rethinking this a bit, the conversion between numbers and ints is more
on the character side because characters are represented as ints in some
way internally.

> The basic principle is that a type conversion method is either a
> method on the source type, or it is a constructor of the result type.

Well, I don't by the either/or. In some cases conversions are better
done by functions, not methods or constructors.

> In either case, it should have the result type's
> name.
> The second case is somewhat more difficult in Python, since it
> does not have multiple constructors.

Well, constructors can behave differently depending on the types, number
and names of the parameters and often enough they do.

> Now you're confusing two different things. The purpose of ord() and
> chr() is to extract a character into an int so that it can then be
> recreated.

Yes. Thinking about it more it makes sense to think about chr and ord
that way. That means they expose an implementation detail of strings, so
ISTM that if they have to be methods they both belong to str (chr would
have to be a class method then).

> I don't see any reasonable use for an encoding operand in ord().

If ord/chr expose the implementation details of strings/characters than
this is indeed not necessary and ord simply returns the number that
represents the character in the string.

> Also, your arguement depends on implementation considerations
> (one couldn't expect that e.g. int knows about encodings.)

That's not an implementation consideration. Even conceptually ints are
much more fundamental than strings. You need ints to talk about strings
-- strings have a length, each item is represented internally by an int
-- but you don't need strings to talk about ints (well if a human
talks/writes about ints some form of textual representation usually
comes into play, but I think my meaning is clear).

> Making type conversions global functions simply
> leads to a combinatorial explosion of global functions, something
> that should be avoided if at all possible.

You don't have to make all of them functions. In many cases implementing
them as methods or constructors is fine.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
MapIt!                                           http://www.mapit.de/