vdf.dump doesn't seem to work with io module

[ondrowan]

I was trying to figure out some example for dumps I'd use in VDF documentation when I noticed it works well with built-in open, but fails with io module.

This works (with Python 2.7.6):

>>> f = open('dump.vdf', 'w+')
>>> vdf.dump({u"key": u"value", u"list": [1, 2, 3]}, f)
>>> f.close()

This fails:

>>> import io
>>> with io.open('dump.vdf', 'w', encoding='utf-16') as file:
...     vdf.dump({u"key": u"value", u"list": [1, 2, 3]}, file)
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "steam/vdf.py", line 196, in dump
    stream.write(_run_dump(obj))
TypeError: must be unicode, not str

io.write expects input string to be unicode while _run_dump returns UTF-16 encoded str.

I'm not using this module, so no idea if this is intended use. Some clarification would be great.

[Lagg]

I'm actually rather surprised that this is an issue since we're technically operating by the "decode in, encode out" rule made official by 3. If I recall correctly io is a 3.0 backport intended specifically to find issues like this. On the other hand, you're not supposed to be using io directly unless implementing a new stream type. I'm unsure how to classify this since the standard filestream interfaces work.

[ondrowan]

I'm not sure myself, but I'd at least cover stream functions with tests. As it's low prio, I'll look into it later. Maybe there will be a better way to implement it, so it works for all cases.

[Lagg]

Yeah, good idea. I (or as of late, @RJacksonm1 ) pretty much covered every syntactical case but not the actual writers. Guess it never came to mind. Which is hilarious since Python 2 and 3 compatibility issues are more often than not encoding related. Hell, even just python issues in general. Don't worry too much about it though because certain backported modules were written to grok the new raw bytes type so it's hard to negotiate non-public or otherwise "unusual" interfaces.

[Lagg]

Oh my god I forgot about the unicode nightmare in 2 and especially 2-to-3 compat hax.

I have to be honest I'm working more on projects like this and python projects haven't really been in my radar for a few years (hence my inactivity there) but I do intend to make a pass and will probably gut all the old py2 stuff probably stopping this from working weirdly.

Given that py3 is affectively debian-level supported now though, I'm not sure anything more on this will be necessary beyond that. Heh