Breaks with Python < 2.7

[robnewman]

Pasted from the original repo merge pull request (https://github.com/sebix/python-textile/pull/9) as per @ikirudennis comment.

Your release breaks if you use any Python release < 2.7 w.r.t. table rendering. Here is a simple test case:

Python 2.6:

Python 2.6.6 (r266:84292, Aug 28 2012, 10:55:56) 
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import textile
>>> s="""
... _This_ is a *test*
... """
>>> html = textile.textile(s)
>>> print html
    <p><em>This</em> is a <strong>test</strong></p>
>>> t="""
... |^.
... |_. Foo|_. Bar|_. Baz|
... |-.
... |this|is|test|
... """
>>> html = textile.textile(t)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/path/to/python2.6/site-packages/textile/functions.py", line 1580, in textile
    html_type=html_type)
  File "/path/to/python2.6/site-packages/textile/functions.py", line 258, in textile
    text = self.block(text, int(head_offset))
  File "/path/to/python2.6/site-packages/textile/functions.py", line 754, in block
    cite, line)
  File "/path/to/python2.6/site-packages/textile/functions.py", line 872, in fBlock
    content = self.graf(content)
  File "/path/to/python2.6/site-packages/textile/functions.py", line 1058, in graf
    text = self.table(text)
  File "/path/to/python2.6/site-packages/textile/functions.py", line 447, in table
    return pattern.sub(self.fTable, text)
  File "/path/to/python2.6/site-packages/textile/functions.py", line 457, in fTable
    for row in [x for x in re.split(r'\|\s*?$', match.group(3), flags=re.M) if x]:
TypeError: split() got an unexpected keyword argument 'flags'

It works under 2.7:

Python 2.7.1 (r271:86832, Aug  5 2011, 03:30:24) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import textile
>>> s="""
... _This_ is a *test*
... """
>>> html = textile.textile(s)
>>> print html
    <p><em>This</em> is a <strong>test</strong></p>
>>> t="""
... |^.
... |_. Foo|_. Bar|_. Baz|
... |-.
... |this|is|test|
... """
>>> html = textile.textile(t)
>>> print html
    <table>
        <thead>
            <tr>
               <th>Foo</th>
               <th>Bar</th>
               <th>Baz</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <td>this</td>
                <td>is</td>
                <td>test</td>
            </tr>
        </tbody>
    </table>
>>>

I understand that this is due to how Python has implemented re.split() under 2.7 - "Changed in version 2.7: Added the optional flags argument."

You might like to update your fork to handle Python < 2.7. At the very least you should explicitly tell users in your forks README that your release breaks Textile table rendering (and maybe elsewhere where you use the re.split() method).

[aclark73]

Is there a reason not to update to 2.7? I don't want to get on a release treadmill, but it seems like 2.7 has some compelling features.

Doesn't help with the non-pypi access, but that's another story...

Adam

On Dec 27, 2012, at 1:53 PM, Rob Newman notifications@github.com wrote:

Pasted from the original repo merge pull request (sebix#9) as per @ikirudennis comment.

Your release breaks if you use any Python release < 2.7 w.r.t. table rendering. Here is a simple test case:

Python 2.6:

Python 2.6.6 (r266:84292, Aug 28 2012, 10:55:56) 
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import textile
>>> s="""
... _This_ is a *test*
... """
>>> html = textile.textile(s)
>>> print html
    <p><em>This</em> is a <strong>test</strong></p>
>>> t="""
... |^.
... |_. Foo|_. Bar|_. Baz|
... |-.
... |this|is|test|
... """
>>> html = textile.textile(t)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/path/to/python2.6/site-packages/textile/functions.py", line 1580, in textile
    html_type=html_type)
  File "/path/to/python2.6/site-packages/textile/functions.py", line 258, in textile
    text = self.block(text, int(head_offset))
  File "/path/to/python2.6/site-packages/textile/functions.py", line 754, in block
    cite, line)
  File "/path/to/python2.6/site-packages/textile/functions.py", line 872, in fBlock
    content = self.graf(content)
  File "/path/to/python2.6/site-packages/textile/functions.py", line 1058, in graf
    text = self.table(text)
  File "/path/to/python2.6/site-packages/textile/functions.py", line 447, in table
    return pattern.sub(self.fTable, text)
  File "/path/to/python2.6/site-packages/textile/functions.py", line 457, in fTable
    for row in [x for x in re.split(r'\|\s*?$', match.group(3), flags=re.M) if x]:
TypeError: split() got an unexpected keyword argument 'flags'

It works under 2.7:

Python 2.7.1 (r271:86832, Aug  5 2011, 03:30:24) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import textile
>>> s="""
... _This_ is a *test*
... """
>>> html = textile.textile(s)
>>> print html
    <p><em>This</em> is a <strong>test</strong></p>
>>> t="""
... |^.
... |_. Foo|_. Bar|_. Baz|
... |-.
... |this|is|test|
... """
>>> html = textile.textile(t)
>>> print html
    <table>
        <thead>
            <tr>
               <th>Foo</th>
               <th>Bar</th>
               <th>Baz</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <td>this</td>
                <td>is</td>
                <td>test</td>
            </tr>
        </tbody>
    </table>
>>>

I understand that this is due to how Python has implemented re.split() under 2.7 - "Changed in version 2.7: Added the optional flags argument."

You might like to update your fork to handle Python < 2.7. At the very least you should explicitly tell users in your forks README that your release breaks Textile table rendering (and maybe elsewhere where you use the re.split() method). — Reply to this email directly or view it on GitHub.

[robnewman]

@aclark73: Sure - we can do that. We will need to talk to our sysadmins about it. I think it is still a valid issue however, especially as the original repo does work with 2.6.

[ikirudennis]

I can understand that maybe someone is using another dependency that is blocking the upgrade. Supporting python 2.6 is a reasonable expectation of backward compatibility in that case and as @robnewman mentions above about making system-wide upgrades. For the time being, this is not high-priority, but when you consider that this is the first and only bug that's been reported, there's not a lot of other bugs keeping me from solving this one.

[ikirudennis]

I updated the README and created a new branch that is Python 2.6-compatible. I hope that helps.

We were lucky here that those incompatible changes were just helpful shorthands for existing functionality and easy to backport to work on previous versions. Further development on the py26 branch may depend on how easy it is to backport the master branch.