[Biopython-dev] Python 2 and 3 migration thoughts

[Peter Cock]

On Tue, Oct 22, 2013 at 5:35 PM, Eric Talevich wrote:
> On Tue, Oct 22, 2013 at 6:59 AM, Peter Cock wrote:
>>
>> Separately, regarding the imports issue - do people have
>> a preference on the try/except as demonstrated here
>> https://github.com/biopython/biopython/pull/249 versus
>> a compatibility layer in Bio._py3k, or a bundled copy of
>> 'six'?
>>
>> e.g. https://github.com/peterjc/biopython/tree/builtins
>> e.g. https://github.com/peterjc/biopython/tree/six
>>
>> Thanks,
>>
>> Peter
>
> I just looked at the source code for six:
> https://bitbucket.org/gutworth/six/src/db5564076aa8/six.py?at=default
>
> It's very compact, much shorter than I expected but also quite dense. I get
> the sense they've had enough eyes on the codebase to sort out performance
> issues and edge cases, e.g. sys.MAXSIZE on Jython.

They've fixed two little bugs I reported, but this remains open:
https://bitbucket.org/gutworth/six/issue/41/from-sixmovestkinter-import-and-similar

I'm avoiding it though:
https://github.com/biopython/biopython/commit/c36fdbaad432d477c64ad5768df7062340530176

> For docstrings, I agree that directly showing the try/except block is more
> informative for users on either genus of Python.

Agreed.

> For the rest of the
> codebase, I would favor using a bundled copy of six (e.g. Bio._six). The
> benefits are (a) not having to discover and fix all the subtle bugs
> ourselves, (b) to be explicit about where we've done something for Py2/3
> compatibility and not as an essential part of the way the code is supposed
> to work, and (c) six has its own documentation.
>
> I also see some virtue in not relying on six/Bio._py3k where it's not
> necessary, since six is compatible back to Python 2.4 and we only go back to
> Python 2.6 now. Halfway approach: just look at six and copy only the bits we
> need into _py3k?

OK, I'll focus in that direction then. Six is MIT licensed so we should
be fine bundling it or extracting snippets.

Thanks,

Peter