Unicode by default (was: Py3k port of python-daemon)

[Aaron Maxwell]

Hey Ben,

That wasn't so bad, once I sat down to do it.  Here are the new bundles 
(uncompressed this time):

http://files.redsymbol.net/bfinney/python-daemon-amax-py3k.v2

http://files.redsymbol.net/bfinney/lockfile-amax-py3k.v2

Includes all the things you note in both your emails, for daemon and lockfile. 
As before, there is one failing test 
(test_return_set_omits_streams_without_file_descriptors in test_daemon.py), but 
the module can power a couple of simple daemon programs I tried without 
obvious mayhem.  Remember you need my hastily-py3k-ported minimock to run any 
tests:

http://files.redsymbol.net/bfinney/minimock.tar.gz
 
I realized just a few minutes ago that the tests for this ported lockfile don't 
pass.  May just be issues in minimock, though.  Mocking libraries in general 
tend to depend on more "magic" features of the language, a foundation that has 
certainly shifted in the 2 -> 3 transition.

The lockfile bundle above does include a minor change that fixed some of the 
lockfile tests' complaints (related to __builtin__ vs. builtins).  I won't have 
time to dig into them any deeper, I'm afraid.

Ben, let me know what you think.  FYI I'm going to be busy the rest of this 
week and REALLY busy this weekend (like, not even checking email), so take 
your time.

Cheers,
Aaron


On Tuesday 29 May 2012 17:54:32 Ben Finney wrote:
> Aaron Maxwell <amax at redsymbol.net> writes:
> > Based on my experiences porting Python-daemon 1.5.5 to work on our
> > Python 3.2 stack, I have ported it to over to the (recent) tip of the
> > mainline branch. Ben, you can get the merge bundles here (created via
> 
> > bzr send):
> Thanks very much for this work.
> 
> Wow, all those Python 2 unicode literals just make the diff really noisy
> don't they? I now regret the work that went into specifying every
> unicode literal; at the time, though, I was needing to support older
> versions in the Python 2.x series.
> 
> To help this process, I will make the code base use unicode literals by
> default (with ‘from __future__ import unicode_literals’) and specify
> bytes literals in those few places where they're needed.
> 
> Specifying a bytes literal only works in Python versions 2.6 or newer,
> which we've already declared a while ago, so it's fine.
> 
> > http://files.redsymbol.net/bfinney/lockfile-amax-py3k.gz
> > 
> > http://files.redsymbol.net/bfinney/python-daemon-amax-py3k.gz
> > 
> > (Please let me know if they are in a usable format for you - I'm still
> > kind of learning bzr.)
> 
> Uncompressed is better, since I can just point Bazaar straight at them;
> but otherwise, that's great.
> 
> Can you merge from the public ‘python-daemon.devel’ branch, which will
> give you the changes to literals. You should have few merge conflicts,
> because most of the string literals change exactly as you've done, but
> there will be a few bytes literals for you to incorporate into your
> branch.
> 
> Then you can re-generate a merge request, which should be considerably
> smaller without all the unicode-literal noise.
> 
> Thanks again for working on this!

-- 
Aaron Maxwell
http://redsymbol.net