Comment on draft PEP for deprecating six builtins

[Roman Neuhauser]

> From: Bernhard Herzog <bh at intevation.de>
> Subject: Re: Comment on draft PEP for deprecating six builtins
> To: python-list at python.org
> Date: 30 Apr 2002 14:19:51 +0200
> 
> 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.

    What I wanted to say was that join() should be a list method, not
    that it should be in __builtin__.
 
> > > [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 :) )

    IMO yes.
 
> 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. 
 
    chr() pukes on anything different than int or float AFAICT. int()
    insists on getting a single character. quite simple, IMO.

> 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).
 
    I didn't say that chr(), whether it's in __builtin__ or int/float
    method should be charset aware. That's out of the scope of this
    discussion.

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

    I don't know whether my preference for chr() being a method of
    int/float objects is influenced by the fact that I like C(-like
    languages). I know that I feel that the ability to express itself as
    a string does belong to int/float objects. Vice versa for strings
    and int() etc.

-- 
FreeBSD 4.4-STABLE
2:49PM up 1 day, 5:15, 11 users, load averages: 0.07, 0.08, 0.05