Comment on draft PEP for deprecating six builtins

[John Roth]

"Bernhard Herzog" <bh at intevation.de> wrote in message
news:6qn0vlbcpk.fsf at abnoba.intevation.de...
> Roman Neuhauser <neuhauser at mail.cz> writes:
>
> > > From: Bernhard Herzog <bh at intevation.de>
> > > Why should chr be an int method in the first place? It's not tied
to
> > > ints all that much[1]. IMO it sits somewhere between ints
(including
> > > int-like objects !) and strings so it shouldn't be a method of
either
> > > class. Leaving it a function is perfectly fine, therefore,
although
> > > putting it into the string module might be a good idea. The same
would
> > > apply to ord, IMO.
> >
> >     Ugh, that looks to me as appropriate as join() being a string
> >     method / module function.
>
> Exactly. I still think that join as a function makes more sense than
as
> a string method and for the same reasons as stated for chr above. Even
> if join is implemented as a string method.

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).

I'm against making such things global functions for a number of
reasons, not least of which is the potential combinatorial explosion.
Also, in a "pure" OO language, there would be very few global
functions; Python has way too many for me to consider it to be
good in that regard.

>
> > > [1] In fact, chr today accepts any object that can be converted
> > > successfully to an int, so that chr(42.5) does work, but that's
not
> > > always desirable.
> >
> >     Any object that can be converted to a character should have a
chr()
> >     method.
>
> Would the same reasoning apply to objects that can be converted to
ints,
> for example. I.e. should strings have a method .int() instead of int
> taking a string as argument (among other types)? (forgetting for the
> moment, that it's actually implemented through the __int__ method :) )

We've got a slightly different principle here; int() is a type
constructor,
while chr() is not. chr() creates a single character string. It is
explicitly
the inverse of ord().

> 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. 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. 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.

> The correspondence between characters depends on an encoding,
something
> which chr and ord do not take into account at all, for example, and
one
> couldn't expect that e.g. int knows about encodings, so that a chr
> method could take the encoding as argument (perhaps defaulting to
> ascii).

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.
These functions are holdovers from earlier languages, and fail miserably
if you want to do character set conversions.

I don't see any reasonable use for an encoding operand in ord().
Consider that strings should know their encoding. This isn't true
currently, but it really should be. In that case, <string>.ord()
produces
the integer index into the encoding, and <string>.encoding() produces
the object that defines the encoding. In the inverse case,
<int>.chr(<encoding>) produces a string with the character from that
encoding.

Character set conversions are best done by string to string functions
or methods. I don't see any benefit in trying to extend ord() and chr()
to handle character set conversions.

Also, your arguement depends on implementation considerations
(one couldn't expect that e.g. int knows about encodings.) Sometimes
you have to take these into consideration, but you should strive
to leave them out if at all possible.

> Of course, whether a conversion operation should be a method, a
function
> or a constructor is largely a matter of taste and is influenced by
> whatever other languages one is coming from. For someone with a
> C-background, characters are ints, so making chr an int method may
seem
> appropriate from that perspective.

It's only a matter of taste until you experiance the heartburn from
what you just ate. Making type conversions global functions simply
leads to a combinatorial explosion of global functions, something
that should be avoided if at all possible.

As far as methods versus constructors goes, conversion methods
chain nicely. Constructors don't. There are situations where one or
the other leads to clearer expression. I suppose that this means one
should do it both ways.

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