|
From: Ron G. <ro...@fl...> - 2009-02-14 03:22:42
|
I realize I'm a little late to the party, but is there a reason you
didn't just construct an RE that matched CamelCase outside of links,
and then run that at the very end?
This nearly works:
>>> re1 = re.compile(r'(?:<a .+?>.+?</a>.*?)*\b((?:[A-Z]+[a-z-_]+)
{2,})\b')
>>> re1.findall('<a href=ThisWontMatch>NeitherWillThis</a>ButThisWill')
['ButThisWill']
It falsely matches embedded CamelCase at the end of a string:
>>> re1.findall('<a href=ThisWillMatchButItShouldnt>SoWillThis</a>')
['ThisWillMatchButItShouldnt', 'SoWillThis']
You can hack around this by appending a sentinal CamelCase string at
the end to generate an extraneous match, and then just ignore that
match. (There's probably a way to fix the RE to do the Right Thing
but I'm not such a studly RE hacker.)
rg
On Feb 11, 2009, at 9:21 PM, Waylan Limberg wrote:
> On Wed, Feb 11, 2009 at 10:34 PM, Yuri Takhteyev
> <qar...@gm...> wrote:
>>> OK, thanks. Is there any projection on when 2.0 will be released?
>>
>> Good question. Do we have any outstanding issues? I had a plan of
>> changing all the processors from run() to __call__(), but I've given
>> up on this plan since. So, unless we have any specific bugs, we
>> should
>> just release it.
>>
>
> I have two things on my list. Unfortunately, I haven't had time to
> work on anything lately. I have a solution for both (in my head), I
> just haven't implemented them yet. Once I do, I'll let everyone know.
>
> In case your wondering, the two items are:
> 1. Lists currently only nest one level with the new core -
> interestingly no tests were checking deeper than that so I didn't
> catch it right way. This is a *must have* IMO, so we need to wait for
> this before releasing. If ElementTree Elements had references to their
> parents this would be *a lot* easier. While I'm at it, I also have one
> minor change to the API for the blockprocessors in mind - so this
> needs to happen before we lock into 2.0.
>
> 2. The fenced_code_block extension needs some cleanup per discussion
> on the markdown list. This is a pretty simple adjustment to the regex
> and should be easy enough. Nice to have, but probably not a
> show-stopper.
>
> There is also some more documentation work to do. The important stuff
> is documented in the source and up-to-date (we'll copy it to the wiki
> when we release), but some of the extensions need their documentation
> updated (such as the new wikilinks ext). Again, not a show stopper. If
> someone wants to help out, patches are welcome adding docs for each
> extension to the repo based on what is currently in the wiki.
>
> --
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
|