On Wed, Apr 29, 2009 at 12:40:24PM -0700, Patrick Mullen wrote: > On Tue, Apr 28, 2009 at 3:39 PM, Marius Gedminas <marius@xxxxxxxxx> wrote > > >>> 1.8 misc > > >>> ====================== > > >>> 1.8.1 support iter protocol > > >>> 1.8.2 str(v) -> "[x, y, z]" > > >>> 1.8.3 repr(v) -> "Vec<x, y, z>" > > >> > > >> Most objects have the same output for str() and repr(). Why do you > > >> differ here? > > > > > > with repr I wanted to make explicitly clear that this is not a list but I > > > thought that the normal str() would look nicer that way. what would you > > > suggest? "[x, y, z]" for both (or "(x, y, z)" if we choose to make > > > vectors immutable) or "Vector3d<x, y, z>"? > > > > I'm +0.95 for distinct __str__ and __repr__. str is what you show your > > users and should be short and clear, while repr is what you give the > > programmers who're debugging and therefore exact types matter. > > > > As far as I understand it, __repr__ is supposed to give you a representation > that can reproduce an equivalent object. "Supposed to" is too strong, but yes, if that's not too cumbersome, it's a good idea. > In other words, eval(repr(ob)) == > ob. I'm not sure if this property is true in all cases where __repr__ has > been used, Definitely not. > but it holds for python standard types. Not all of them. > I think it's more of a > consideration than a full on standard. Yep. > Still, I would prefer then to have > the __repr__ be "Vector3d(x, y, z)" if that is in fact the constructor of a > vector3d. Of course this doesn't matter much. Yes and yes. Marius Gedminas -- Bumper sticker: Alcohol and calculus don't mix. Never drink and derive.
Attachment:
signature.asc
Description: Digital signature