Skip to content
Permalink
Branch: master
Commits on Mar 8, 2014
  1. widgets: Fix faulty save_state() under Python 3

    hsoft committed Mar 8, 2014
    The result of `toBase64().data()`, bytes data, was wrapped into a string
    using `ustr()` causing the resulting trying to be a *representation* of
    the bytes (wrapped into `b''`), thus being buggy data.
    
    I've replaced this with a proper ".decode()" call.
    
    I've tried keeping it as bytes, but that didn't go through
    serialization.
    
    Fixes #236
    
    Signed-off-by: Virgil Dupras <hsoft@hardcoded.net>
Commits on Feb 23, 2014
  1. modernize: Use io.StringIO instead of cStringIO

    hsoft committed Feb 23, 2014
    It turns out that Python has its `io` modules since Python 2.6,
    something I didn't know. It simplifies the two previous `cStringIO` uses
    and removes the need for a `compat.StringIO`.
    
    Signed-off-by: Virgil Dupras <hsoft@hardcoded.net>
Commits on Feb 22, 2014
  1. modernize: Added support for Python 3

    hsoft committed Feb 22, 2014
    Cola now runs on both Python 2.6+ and 3! Many refactorings were
    necessary for this.
    
    In-house "six-like" compat unit: Because there were only a few
    compatibility tricks needed, I felt that it was overkill to add a
    dependency on the "six" module, so I added the necessary compatibility
    tricks in cola.compat:
    
    * ustr: replaces all previous instances of `unicode`.
    * unichr: Alias of `chr` under py3.
    * StringIO: Import from `cStringIO` under py2 and `io` under py3.
    * urllib: Aliases to `urllib.parse` under py3.
    
    Then, there's a couple of small fixes that had to be made:
    
    * StandardError --> Exception
    * except foo, e --> except foo as e
    * foo.reverse() --> reversed(foo)
    * xrange() --> range() (minimal perf impact under py2)
    * iteritems() --> items() (minimal perf impact under py2)
    * Wrapping list() where needed (filter(), map(), etc.)
    * __next__ = next aliasing
    
    Also, there were a couple of places where `core.encode()` was used and
    didn't have to. Under py2, it did nothing, but under py3, it generated
    an error. I've tried to be as careful and minimal as possible for that
    part, but if there's one area where there's a risk of newly indtroduced
    bugs, it's that part.
    
    There were also "cmp" functions that had to be replaced with "key"
    functions.
    
    Signed-off-by: Virgil Dupras <hsoft@hardcoded.net>
  2. modernize: Added "unicode_literals" __future__ import

    hsoft committed Feb 22, 2014
    Also, replaced the few "u" literals spread across the code with normal
    string literals.
    
    Signed-off-by: Virgil Dupras <hsoft@hardcoded.net>
  3. modernize: Removed utils.ProgressIndicator

    hsoft committed Feb 22, 2014
    ProgressIndicator, which isn't used anywhere, is the only place where we
    use a print statement. Rather than modernizing it with a
    "print_function" __future__, I've simply removed it.
    
    Signed-off-by: Virgil Dupras <hsoft@hardcoded.net>
  4. modernize: Added "absolute_import" __future__ import

    hsoft committed Feb 22, 2014
    No further adjustments were required, the code was already clear of
    ambiguous imports.
    
    Signed-off-by: Virgil Dupras <hsoft@hardcoded.net>
  5. modernize: Minimum Python version is now 2.6

    hsoft committed Feb 22, 2014
    That allowed us to remove some dead weight in cola.compat.
    
    Signed-off-by: Virgil Dupras <hsoft@hardcoded.net>
Commits on Feb 21, 2014
  1. modernize: Added "division" __future__ import

    hsoft committed Feb 21, 2014
    Added "from __future__ import division" in every python unit of the
    project. Wherever there was division going on, ensured that it was still
    correct and modern.
    
    Signed-off-by: Virgil Dupras <hsoft@hardcoded.net>
Commits on Feb 16, 2014
  1. i18n: Fixed i18n_test by setting the LANGUAGE env variable

    hsoft committed Feb 16, 2014
    When I ran i18n_test, I had failures on 'ja_JP' and 'de_DE' tests. After
    a little search, it turns out that gettext was unable to find the proper
    mo files. cola's approach to setting up its translation is to set
    environement variables and then call `translation()` without a
    `languages` argument.
    
    Before this patch, the environment variables we set were "LANG" and
    "LC_MESSAGES". However, this is what Python doc for `find()` says:
    
    """
    If languages is not given, then the following environment variables are
    searched: LANGUAGE, LC_ALL, LC_MESSAGES, and LANG. The first one
    returning a non-empty value is used for the languages variable.
    """
    
    Therefore, non-empty "LANGUAGE" or "LC_ALL" env variables would
    mess up our translation.
    
    I've added a line setting "LANGUAGE" (in addition to the two others
    already there) and it fixed the tests for me.
    
    Signed-off-by: Virgil Dupras <hsoft@hardcoded.net>
You can’t perform that action at this time.