Output of TAG to string about nbt HOT 6 CLOSED

Here are my preferences:

1. b (c is more 'correct', but not very practical). I'm opposed to a, since it does not follow Python guidelines and I found it very unhelpful.
2. c or b, or combination thereof (I like to see the type listed, but admittedly that is not very common in Python, and more suitable to repr.). I do not mind removing one of the 4 functions, and b allows elimination of tag_info. However, people will be used to tag_info by now, so I wouldn't actually remove it, eliminating the advantage.
3. b or c
4. b
5. b is probably more correct; I like a though.
6. a (there is a reason Python 3 changed the bytes/str/unicode mess of Python 2. I don't think it's our job to solve that here. Also str() is not used that often, even considering output like '%s' % TAG_object; so I don't mind the occasional exception).

from nbt.

You have convinced me. I originally wrote the pretty_tree formatter to output byte-for-byte what was written in the initial spec put up by markus, however the newer code makes more sense, and is more correct. (Not to mention the spec no longer exists :-{ )

The one thing that I think should change however is that everything should emit unicode unless str is explicitly asked for. This works for python3 much better and It wouldn't hurt to give the python2 guys a kick in the pants.

from nbt.

Perhaps the Python 2 answer is to include a __unicode__ function (instead of | in addition to)? the __str__ function. I'm interested to find out, but no promise on a time schedule (some busy weeks at work coming up)

from nbt.

Yes indeed, __str__ should just downgrade output of the __unicode__ method.

from nbt.

I know that the UnicodeMixin as mentioned by http://docs.python.org/howto/pyporting.html#str-unicode advises that __str__ just encodes ("downgrade") output of __unicode__, but I think that is bad advice.

In my opinion, a program should decode the (string) input, and encode the output. Thus the encoding should only happen in the print() function for interactive output (which uses a variable encoding, depending on the TTY environment), or in the fileobject.write() function. (e.g. sys.stdout.write(myoutput.encode('utf-8'))) for non-interactive output, which should have a fixed encoding (for consistent output). Doing the encoding in str is in my opinion bad, because it does so somewhere in the middle of the program (not associated with output to the user). Even worse, the encoding chosen by __str__ may be plain wrong.

For reference, this is an overview which string conversion functions call which methods:

In this table, green function always return Unicode, and red function always return byte strings.

Concluding, if you want to preserve Unicode strings (instead of silently converting to byte strings, with all its problems) in Python 2, and like to use code that also works in Python 3, there are two things you can do:

try:
    unicode
except NameError:
    unicode = str   # Python 3 compatibility

myunicodestring = "%s" % myobject

or

from __future__ import unicode_literals

myunicodestring = "%s" % myobject

Both solution call __unicode__ in Python 2, and __str__ in Python 3.

These functions can thus be defined as follows:

def __unicode__(self):
    """Return unicode string. Used in Python 2."""
    return unicode(self.value)

def __str__(self):
    """Return byte string in Python 2 and unicode string in Python 3."""
    return unicode(self.value)

While at first it seems hard to make sure that __str__ behaves differently in Python 2 and Python 3, this happens to be the Python specs (which I can't change), and in practise you will find that both code are usually exactly the same.

I'll make a patch when work allows.

from nbt.

Wow, GitHub automatically closed this because of the text in the commit message. Smart GitHub.

Anyway, I happy it's closed. I clearly overthought this one. Hmm, is overthought the correct conjugate of overthinking? Hmm, maybe I should start a lengthy discussion how to conjugate ..... SMACK .....

from nbt.