Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #56739 > unrolled thread

Re: Unicode Objects in Tuples

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Unicode Objects in Tuples Ned Batchelder <ned@nedbatchelder.com> - 2013-10-12 06:52 -0400
    Re: Unicode Objects in Tuples Roy Smith <roy@panix.com> - 2013-10-12 09:11 -0400

#56739 — Re: Unicode Objects in Tuples

On 10/12/13 2:20 AM, Ian Kelly wrote:
> On Fri, Oct 11, 2013 at 7:31 AM, Stephen Tucker <stephen_tucker@sil.org> wrote:
>> On the original question, well, I accept Ned's answer (at 10.22). I also
>> like the idea of a helper function given by Peter Otten at 09.51. It still
>> seems like a crutch to help poor old Python 2.X to do what any programmer
>> (or, at least the programmers like me :-)  ) think it ought to be able to by
>> itself. The distinction between the "geekiness" of a tuple compared with the
>> "non-geekiness" of a string is, itself, far too geeky for my liking. The
>> distinction seems to be an utterly spurious - even artificial or arbitrary
>> one to me. (Sorry about the rant.)
> I agree, and that's not how I would explain the distinction.  The str
> of an object is meant to be human-readable, while the repr of an
> object is meant to be something that could be pasted into the
> interpreter to reconstruct the object.  In the case of tuples, the
> repr of the tuple uses the reprs of the components because the
> resulting string will more likely be acceptable to the interpreter,
> and the str of the tuple is the same as the repr because there is no
> convincing reason why it should be different.

This idea that the repr can reconstruct the object always fell flat with 
me since the vast majority of classes don't have a repr that works that 
way.  I look at it a little differently: the repr is meant to be as 
unambiguous as possible to a developer.  It turns out that Python 
literal syntax is really good at that, so where possible, that's what's 
used.   But most classes don't make an attempt to create a Python 
expression, because that's very difficult, and in fact, the literal 
syntax may not be useful:

     >>> object()
     <object object at 0x1088bb0d0>

Here, the valid Python syntax is "object()", but that's useless as a 
repr, because it doesn't help you distinguish between two instances.

In fact, you say repr could be used to "reconstruct the object", but 
really what you mean is "reconstruct an equal object".  There is no way 
to construct an equal object(), so right at the root of the Python 
object hierarchy, repr doesn't even attempt it.

--Ned.

[toc] | [next] | [standalone]

#56744

In article <mailman.1034.1381575143.18130.python-list@python.org>,
 Ned Batchelder <ned@nedbatchelder.com> wrote:

> This idea that the repr can reconstruct the object always fell flat with 
> me since the vast majority of classes don't have a repr that works that 
> way.  I look at it a little differently: the repr is meant to be as 
> unambiguous as possible to a developer.  It turns out that Python 
> literal syntax is really good at that, so where possible, that's what's 
> used.   But most classes don't make an attempt to create a Python 
> expression, because that's very difficult

Well, it's not actually difficult.  You could imagine doing something 
like:

def __repr__(self):
    return "pickle.loads(%s)" % pickle.dumps(self)

and while you can paste that into a REPL, it's not really useful to most 
people.

What we do with our database model layer is have the repr include the 
name of the class and the primary key.  So:

>>> str(u)
'roysmith'
>>> repr(u)
"<User 1000564: u'roysmith'>"

That follow's Ned's idea that reprs should be unambiguous.  In this 
case, if I want to reconstitute myself as an object, I can just do a 
database query for user_id = 1000564.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web