Comments (6)
Here are my preferences:
- 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.
- 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.
- b or c
- b
- b is probably more correct; I like a though.
- 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:
code | Python 2 | Python 2 with Unicode literals | Python 3 |
---|---|---|---|
print(s) | __str__ or __repr__ | __str__ or __repr__ | __str__ or __repr__ |
'%s' % s | __str__ or __repr__ | __unicode__ or __str__ or __repr__ | __str__ or __repr__ |
str(s) | __str__ or __repr__ | __str__ or __repr__ | __str__ or __repr__ |
unicode(s) | __unicode__ or __str__ or __repr__ | __unicode__ or __str__ or __repr__ | NameError |
repr(s) | __repr__ | __repr__ | __repr__ |
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.
Related Issues (20)
- [Question, Potential Bug Report]: _render_buffer recursion when trying to modify region files in entities folder HOT 1
- [Question] How to get block data from blockstates
- (Question) Trying to modify region binary to replace stuff in minecraft world using blockdata
- KeyError: Tag Level does not exist when using Minecraft 1.18.1 worlds. HOT 3
- Can someone add support for 1.18 world height. Chunk section range should support -4 to 19, not 0 to 15. Thanks!
- Error while creating data: "struct.error: int too large to convert" HOT 1
- Unable to set value for Compound HOT 1
- Writing a compound tag to a file HOT 1
- 'TAG_End' is not defined HOT 3
- Using the map example with a 1.8 world renders nothing but black. HOT 2
- Can't save .mca HOT 2
- Get uncompressed NBT data to variable
- SNBT parser in/out
- Use of TAG_Int_Array unclear/undocumented HOT 2
- `Sample_World.tar.gz` missing? HOT 1
- Continuous integration setup HOT 1
- Policy on compatibility with old Minecraft versions HOT 2
- Opening servers.dat.
- [Bug Report]: UnicodeDecodeError on valid data HOT 1
- Create method to convert SNBT to json/python dict
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nbt.