Menu
▾
▴
python-markdown-discuss
|
From: Artem Y. <ne...@gm...> - 2008-08-04 18:07:24
|
Hello all, I merged GSoC version to our mainline repository and now we close to release 2.0 version(after some testing). Please, try it out. You can take it from repository or just download tarball file: http://splyer.com/markdown2.0.tar.gz |
|
From: Waylan L. <wa...@gm...> - 2008-08-04 19:20:37
|
On Mon, Aug 4, 2008 at 2:07 PM, Artem Yunusov <ne...@gm...> wrote: > Hello all, > > I merged GSoC version to our mainline repository and now we close to > release 2.0 version(after some testing). > Please, try it out. You can take it from repository or just download > tarball file: > > http://splyer.com/markdown2.0.tar.gz > I hate to nitpick, but I wouldn't call this 2.0 yet. Perhaps 2.0-alpha. It gets confusing later when trying to debug bug reports and different people have different versions all labeled the same. I'd suggest renaming that file on your server before to many people download it and it creates a real problem. -- ---- Waylan Limberg wa...@gm... |
|
From: Waylan L. <wa...@gm...> - 2008-08-04 19:33:57
|
On Mon, Aug 4, 2008 at 3:20 PM, Waylan Limberg <wa...@gm...> wrote: > On Mon, Aug 4, 2008 at 2:07 PM, Artem Yunusov <ne...@gm...> wrote: >> Hello all, >> >> I merged GSoC version to our mainline repository and now we close to >> release 2.0 version(after some testing). >> Please, try it out. You can take it from repository or just download >> tarball file: >> >> http://splyer.com/markdown2.0.tar.gz >> > I hate to nitpick, but I wouldn't call this 2.0 yet. Perhaps > 2.0-alpha. It gets confusing later when trying to debug bug reports > and different people have different versions all labeled the same. I'd > suggest renaming that file on your server before to many people > download it and it creates a real problem. > Oh, I see you set the version_info to 2.0.0.beta in the repo, just not in the filename (I still recommend renaming the file). I haven't downloaded the tar.gz file yet (I can't behind the firewall here at work) so I don't know what all it includes, but I prefer to use setup.py to create the distribution files. As long as the setup.py script has the right version info (it appears you did not update that in the repo) it will generate the appropriate file names with all the version info included. -- ---- Waylan Limberg wa...@gm... |
|
From: Artem Y. <ne...@gm...> - 2008-08-04 19:49:37
|
Thanks for the advice, new link is: http://splyer.com/markdown2.0-alpha.tar.gz Waylan Limberg wrote: > On Mon, Aug 4, 2008 at 3:20 PM, Waylan Limberg <wa...@gm...> wrote: > >> On Mon, Aug 4, 2008 at 2:07 PM, Artem Yunusov <ne...@gm...> wrote: >> >>> Hello all, >>> >>> I merged GSoC version to our mainline repository and now we close to >>> release 2.0 version(after some testing). >>> Please, try it out. You can take it from repository or just download >>> tarball file: >>> >>> http://splyer.com/markdown2.0.tar.gz >>> >>> >> I hate to nitpick, but I wouldn't call this 2.0 yet. Perhaps >> 2.0-alpha. It gets confusing later when trying to debug bug reports >> and different people have different versions all labeled the same. I'd >> suggest renaming that file on your server before to many people >> download it and it creates a real problem. >> >> > > Oh, I see you set the version_info to 2.0.0.beta in the repo, just not > in the filename (I still recommend renaming the file). I haven't > downloaded the tar.gz file yet (I can't behind the firewall here at > work) so I don't know what all it includes, but I prefer to use > setup.py to create the distribution files. As long as the setup.py > script has the right version info (it appears you did not update that > in the repo) it will generate the appropriate file names with all the > version info included. > > > |
|
From: Waylan L. <wa...@gm...> - 2008-08-05 19:47:10
|
On Mon, Aug 4, 2008 at 2:07 PM, Artem Yunusov <ne...@gm...> wrote: > Hello all, > > I merged GSoC version to our mainline repository and now we close to > release 2.0 version(after some testing). Artem, now that your patches are merged to trunk, could you close the related tickets. I could do it, but I'm not sure which tickets you've addressed and which you haven't. Thanks. -- ---- Waylan Limberg wa...@gm... |
|
From: Artem Y. <ne...@gm...> - 2008-08-05 21:28:18
|
Waylan Limberg wrote: > On Mon, Aug 4, 2008 at 2:07 PM, Artem Yunusov <ne...@gm...> wrote: > >> Hello all, >> >> I merged GSoC version to our mainline repository and now we close to >> release 2.0 version(after some testing). >> > > Artem, now that your patches are merged to trunk, could you close the > related tickets. I could do it, but I'm not sure which tickets you've > addressed and which you haven't. Thanks. > > > Done. What should I do with ticket#4 ? it's fixed only for not nested parenthesis. Also in 2.0-alpha version any number of parenthesis can be inserted in that way: [link](<()()((()>) |
|
From: Waylan L. <wa...@gm...> - 2008-08-05 21:49:00
|
On Tue, Aug 5, 2008 at 5:28 PM, Artem Yunusov <ne...@gm...> wrote: > > Done. What should I do with ticket#4 ? it's fixed only for not nested > parenthesis. > Also in 2.0-alpha version any number of parenthesis can be inserted in > that way: [link](<()()((()>) > I'd add a comment to the bottom of the report to that effect. Point out that the given example works but nesting does not. I'm tempted to say close it as the report didn't specifically address nesting anyway - and in fact, we may never get it given pythons lack of recursion in the re module. -- ---- Waylan Limberg wa...@gm... |
|
From: Waylan L. <wa...@gm...> - 2008-08-06 15:40:46
|
Artem,
I have finally got a chance to start looking at your work more closely
and really appreciate the time and effort you put into it. I still
need to wrap my head around a few things, but it looks good so far.
Looking through your code, I noticed a few missing or problem doc
strings. I thought you might want to clean them up yourself. If you
haven't already, I'd suggest reading [PEP 257][] first as a guideline.
No doubt you'll notice that we haven't kept to that strictly, but I've
been making an effort to improve in that area recently. In fact, a few
months back I went through and added a significant amount of missing
doc strings.
My policy has been that any class/method/function that extension
writers are likely to use should get a very thorough docstring
spelling everything out, and anything else can have a one-liner
(except that _private methods do not need one). So, for example, would
an extension writer need to use some of your etree helper functions to
build his/her elements for inclusion in the tree? I'm not sure, and I
don't find any hints in the existing docstrings.
Also, in PEP 257 you may want to note this comment with regard to
one-liners (although the principle should apply to all docstrings):
> The docstring is a phrase ending in a period. It prescribes the function
> or method's effect as a command ("Do this", "Return that"), not as a
> description; e.g. don't write "Returns the pathname ...".
It appears that most of your docstrings get that wrong, although its
not too hard to fix. You might want to run a spellcheck on your
docstrings as well ( I saw a few "retruns").
Oh, and one final point, the docstrings should all use markdown
formatting - especially the long ones - for reasons that should be
obvious. I didn't notice any specific problems there, but figured it's
worth pointing out.
I realize this may seem a little nitpicky, and I get the impression
Yuri isn't too worried about it, but it has been something others have
complained about in the past and I really want to get it right before
we release 2.0 final.
[PEP 257]: http://www.python.org/dev/peps/pep-0257/
--
----
Waylan Limberg
wa...@gm...
|
|
From: Waylan L. <wa...@gm...> - 2008-08-06 16:32:59
|
While I'm thinking of it, one other thing that needs to be documented
is the dependency on ElementTree. What's the oldest required version?
Obviously it should be a non-issue for Python2.5, but for those who
have 1.3 or 2.4, they need to know that external library needs to be
installed, and if they happen to have a too-old version already
installed, we should warn them upfront. Perhaps on a successful
import, we should check the version and exit with an appropriate error
message if it's too old.
On Wed, Aug 6, 2008 at 11:37 AM, Waylan Limberg <wa...@gm...> wrote:
> Artem,
>
> I have finally got a chance to start looking at your work more closely
> and really appreciate the time and effort you put into it. I still
> need to wrap my head around a few things, but it looks good so far.
>
> Looking through your code, I noticed a few missing or problem doc
> strings. I thought you might want to clean them up yourself. If you
> haven't already, I'd suggest reading [PEP 257][] first as a guideline.
> No doubt you'll notice that we haven't kept to that strictly, but I've
> been making an effort to improve in that area recently. In fact, a few
> months back I went through and added a significant amount of missing
> doc strings.
>
> My policy has been that any class/method/function that extension
> writers are likely to use should get a very thorough docstring
> spelling everything out, and anything else can have a one-liner
> (except that _private methods do not need one). So, for example, would
> an extension writer need to use some of your etree helper functions to
> build his/her elements for inclusion in the tree? I'm not sure, and I
> don't find any hints in the existing docstrings.
>
> Also, in PEP 257 you may want to note this comment with regard to
> one-liners (although the principle should apply to all docstrings):
>
>> The docstring is a phrase ending in a period. It prescribes the function
>> or method's effect as a command ("Do this", "Return that"), not as a
>> description; e.g. don't write "Returns the pathname ...".
>
> It appears that most of your docstrings get that wrong, although its
> not too hard to fix. You might want to run a spellcheck on your
> docstrings as well ( I saw a few "retruns").
>
> Oh, and one final point, the docstrings should all use markdown
> formatting - especially the long ones - for reasons that should be
> obvious. I didn't notice any specific problems there, but figured it's
> worth pointing out.
>
> I realize this may seem a little nitpicky, and I get the impression
> Yuri isn't too worried about it, but it has been something others have
> complained about in the past and I really want to get it right before
> we release 2.0 final.
>
> [PEP 257]: http://www.python.org/dev/peps/pep-0257/
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>
--
----
Waylan Limberg
wa...@gm...
|
|
From: Artem Y. <ne...@gm...> - 2008-08-06 22:41:07
|
Yep, I'll update doc strings by myself. Thanks for the link to PEP 257.
I think extension writers need to know about markdown.etree module
object, and also, that all data in <inline> tag will be processed by
inline patterns, other functions, like indentETree is useless for them.
I think we should write about all this on site in "Writing Extensions"
section.
Concerning ElementTree version, I made some tests, all versions since
1.1(including) suitable for us. That means that only 1.0 failed. I'll
add version check to importETree function.
Python 2.5 uses ElementTree 1.2.6.
Waylan Limberg wrote:
> Artem,
>
> I have finally got a chance to start looking at your work more closely
> and really appreciate the time and effort you put into it. I still
> need to wrap my head around a few things, but it looks good so far.
>
> Looking through your code, I noticed a few missing or problem doc
> strings. I thought you might want to clean them up yourself. If you
> haven't already, I'd suggest reading [PEP 257][] first as a guideline.
> No doubt you'll notice that we haven't kept to that strictly, but I've
> been making an effort to improve in that area recently. In fact, a few
> months back I went through and added a significant amount of missing
> doc strings.
>
> My policy has been that any class/method/function that extension
> writers are likely to use should get a very thorough docstring
> spelling everything out, and anything else can have a one-liner
> (except that _private methods do not need one). So, for example, would
> an extension writer need to use some of your etree helper functions to
> build his/her elements for inclusion in the tree? I'm not sure, and I
> don't find any hints in the existing docstrings.
>
> Also, in PEP 257 you may want to note this comment with regard to
> one-liners (although the principle should apply to all docstrings):
>
>
>> The docstring is a phrase ending in a period. It prescribes the function
>> or method's effect as a command ("Do this", "Return that"), not as a
>> description; e.g. don't write "Returns the pathname ...".
>>
>
> It appears that most of your docstrings get that wrong, although its
> not too hard to fix. You might want to run a spellcheck on your
> docstrings as well ( I saw a few "retruns").
>
> Oh, and one final point, the docstrings should all use markdown
> formatting - especially the long ones - for reasons that should be
> obvious. I didn't notice any specific problems there, but figured it's
> worth pointing out.
>
> I realize this may seem a little nitpicky, and I get the impression
> Yuri isn't too worried about it, but it has been something others have
> complained about in the past and I really want to get it right before
> we release 2.0 final.
>
> [PEP 257]: http://www.python.org/dev/peps/pep-0257/
>
>
>
|
|
From: Yuri T. <qar...@gm...> - 2008-08-07 00:00:56
|
> Concerning ElementTree version, I made some tests, all versions since
> 1.1(including) suitable for us. That means that only 1.0 failed. I'll
> add version check to importETree function.
> Python 2.5 uses ElementTree 1.2.6.
I tried running the new version with Python 2.5, 2.4 and 2.3. For
2.5, all the tests pass out of the box, no element tree installation
required. For 2.4, I had to install element tree, after which all
works fine. So, we just need to make sure to document this. I think
we should include specific line-by-line instructions on the wiki,
rather than just sending people to element tree website, which I
myself found mildly confusing. E.g., for UNIX:
wget http://splyer.com/markdown2.0.tar.gz
wget http://splyer.com/markdown2.0-alpha.tar.gz
tar xvzf markdown2.0-alpha.tar.gz
cd markdown2.0-alpha/
wget http://effbot.org/media/downloads/elementtree-1.2.6-20050316.tar.gz
tar xvzf elementtree-1.2.6-20050316.tar.gz
mv elementtree-1.2.6-20050316/elementtree .
python2.4 test-markdown.py
Now, for 2.3 I am getting an error, however:
Traceback (most recent call last):
File "test-markdown.py", line 358, in ?
testDirectory("tests/markdown-test", measure_time=True)
File "test-markdown.py", line 246, in testDirectory
actual_output = md.convert(input)
File "/usr/local/tmp/markdown2.0-alpha/markdown.py", line 1929, in convert
xml = codecs.decode(etree.tostring(root, encoding="utf8"), "utf8")
As I realize, this is a line I added myself. Apparently, the codecs
module in 2.3 does not have a "decode" function. I replaced line 1929
with:
xml, length = codecs.utf_8_decode(etree.tostring(root, encoding="utf8"))
after which it seems to all work with python2.3 as well.
I commited the change with
http://gitorious.org/projects/python-markdown/repos/mainline/commits/c78a1e7
Also, another commit to correct placeholder codes to correct STX/ETX
codes, and referring to them accordingly. (Now using ASCII 02 and 03,
rather than 01 and 02.)
http://gitorious.org/projects/python-markdown/repos/mainline/commits/a2e4db6
- yuri
--
http://sputnik.freewisdom.org/
|
|
From: Waylan L. <wa...@gm...> - 2008-08-07 02:34:40
|
On Wed, Aug 6, 2008 at 6:41 PM, Artem Yunusov <ne...@gm...> wrote: > Yep, I'll update doc strings by myself. Thanks for the link to PEP 257. > I think extension writers need to know about markdown.etree module > object, and also, that all data in <inline> tag will be processed by > inline patterns, other functions, like indentETree is useless for them. > I think we should write about all this on site in "Writing Extensions" > section. I agree. Actually, that section needs to be completely reworked as a number of additions/changes have happened to the extension API since that page was last updated. The thing is, we don't want to update that page until after 2.0 final is released or people may expect it to apply to 1.7. I think maybe we should throw a text file in git for now and copy it over the the wiki when we release. If you write up the docs for the stuff you did Artem, I'll do the rest - unless you beat me to it.. -- ---- Waylan Limberg wa...@gm... |
|
From: Waylan L. <wa...@gm...> - 2008-08-07 21:31:55
|
On Wed, Aug 6, 2008 at 10:34 PM, Waylan Limberg <wa...@gm...> wrote: > On Wed, Aug 6, 2008 at 6:41 PM, Artem Yunusov <ne...@gm...> wrote: >> Yep, I'll update doc strings by myself. Thanks for the link to PEP 257. >> I think extension writers need to know about markdown.etree module >> object, and also, that all data in <inline> tag will be processed by >> inline patterns, other functions, like indentETree is useless for them. >> I think we should write about all this on site in "Writing Extensions" >> section. > > I agree. Actually, that section needs to be completely reworked as a > number of additions/changes have happened to the extension API since > that page was last updated. The thing is, we don't want to update that > page until after 2.0 final is released or people may expect it to > apply to 1.7. I think maybe we should throw a text file in git for now > and copy it over the the wiki when we release. If you write up the > docs for the stuff you did Artem, I'll do the rest - unless you beat > me to it.. FYI, I just committed a rough draft. Artem, I left the section on DOM manipulation for you. Any criticisms, suggestions or corrections are welcome. I'll copy it to the wiki when we release 2.0 final. -- ---- Waylan Limberg wa...@gm... |
|
From: Artem Y. <ne...@gm...> - 2008-08-07 23:25:35
|
Waylan Limberg wrote: > On Wed, Aug 6, 2008 at 10:34 PM, Waylan Limberg <wa...@gm...> wrote: > >> On Wed, Aug 6, 2008 at 6:41 PM, Artem Yunusov <ne...@gm...> wrote: >> >>> Yep, I'll update doc strings by myself. Thanks for the link to PEP 257. >>> I think extension writers need to know about markdown.etree module >>> object, and also, that all data in <inline> tag will be processed by >>> inline patterns, other functions, like indentETree is useless for them. >>> I think we should write about all this on site in "Writing Extensions" >>> section. >>> >> I agree. Actually, that section needs to be completely reworked as a >> number of additions/changes have happened to the extension API since >> that page was last updated. The thing is, we don't want to update that >> page until after 2.0 final is released or people may expect it to >> apply to 1.7. I think maybe we should throw a text file in git for now >> and copy it over the the wiki when we release. If you write up the >> docs for the stuff you did Artem, I'll do the rest - unless you beat >> me to it.. >> > > FYI, I just committed a rough draft. Artem, I left the section on DOM > manipulation for you. Any criticisms, suggestions or corrections are > welcome. I'll copy it to the wiki when we release 2.0 final. > Thanks, I'll write about it. One suggestion, I think we should not call ElementTree object - DOM, because it's slightly different things, as far as understand. |
|
From: Waylan L. <wa...@gm...> - 2008-08-08 02:11:36
|
On Thu, Aug 7, 2008 at 7:25 PM, Artem Yunusov <ne...@gm...> wrote: > Waylan Limberg wrote: >> On Wed, Aug 6, 2008 at 10:34 PM, Waylan Limberg <wa...@gm...> wrote: >> >>> On Wed, Aug 6, 2008 at 6:41 PM, Artem Yunusov <ne...@gm...> wrote: >>> >>>> Yep, I'll update doc strings by myself. Thanks for the link to PEP 257. >>>> I think extension writers need to know about markdown.etree module >>>> object, and also, that all data in <inline> tag will be processed by >>>> inline patterns, other functions, like indentETree is useless for them. >>>> I think we should write about all this on site in "Writing Extensions" >>>> section. >>>> >>> I agree. Actually, that section needs to be completely reworked as a >>> number of additions/changes have happened to the extension API since >>> that page was last updated. The thing is, we don't want to update that >>> page until after 2.0 final is released or people may expect it to >>> apply to 1.7. I think maybe we should throw a text file in git for now >>> and copy it over the the wiki when we release. If you write up the >>> docs for the stuff you did Artem, I'll do the rest - unless you beat >>> me to it.. >>> >> >> FYI, I just committed a rough draft. Artem, I left the section on DOM >> manipulation for you. Any criticisms, suggestions or corrections are >> welcome. I'll copy it to the wiki when we release 2.0 final. >> > > Thanks, I'll write about it. One suggestion, I think we should not call > ElementTree object - DOM, because it's slightly different things, as far > as understand. > Go ahead and edit as you see fit. Your certainly more familiar with that part of the code (including the terminology to use) so go for it. I was just using the same old terms we had before. -- ---- Waylan Limberg wa...@gm... |
|
From: Artem Y. <ne...@gm...> - 2008-08-07 23:33:12
|
Yuri Takhteyev wrote: > > I tried running the new version with Python 2.5, 2.4 and 2.3. For > 2.5, all the tests pass out of the box, no element tree installation > required. For 2.4, I had to install element tree, after which all > works fine. So, we just need to make sure to document this. I think > we should include specific line-by-line instructions on the wiki, > rather than just sending people to element tree website, which I > myself found mildly confusing. E.g., for UNIX: > > wget http://splyer.com/markdown2.0.tar.gz > wget http://splyer.com/markdown2.0-alpha.tar.gz > tar xvzf markdown2.0-alpha.tar.gz > cd markdown2.0-alpha/ > wget http://effbot.org/media/downloads/elementtree-1.2.6-20050316.tar.gz > tar xvzf elementtree-1.2.6-20050316.tar.gz > mv elementtree-1.2.6-20050316/elementtree . > python2.4 test-markdown.py > Or for any platform: easy_install http://splyer.com/markdown2.0-alpha.tar.gz easy_install elementtree > Also, another commit to correct placeholder codes to correct STX/ETX > codes, and referring to them accordingly. (Now using ASCII 02 and 03, > rather than 01 and 02.) > > What about AND_SUBSTITUTE ? I use it in some places instead of "&", now it's: AND_SUBSTITUTE = unichr(2) + unichr(4) + unichr(3) is it ok ? |
|
From: Waylan L. <wa...@gm...> - 2008-08-08 02:14:10
|
On Thu, Aug 7, 2008 at 7:33 PM, Artem Yunusov <ne...@gm...> wrote: > Yuri Takhteyev wrote: >> >> I tried running the new version with Python 2.5, 2.4 and 2.3. For >> 2.5, all the tests pass out of the box, no element tree installation >> required. For 2.4, I had to install element tree, after which all >> works fine. So, we just need to make sure to document this. I think >> we should include specific line-by-line instructions on the wiki, >> rather than just sending people to element tree website, which I >> myself found mildly confusing. E.g., for UNIX: >> >> wget http://splyer.com/markdown2.0.tar.gz >> wget http://splyer.com/markdown2.0-alpha.tar.gz >> tar xvzf markdown2.0-alpha.tar.gz >> cd markdown2.0-alpha/ >> wget http://effbot.org/media/downloads/elementtree-1.2.6-20050316.tar.gz >> tar xvzf elementtree-1.2.6-20050316.tar.gz >> mv elementtree-1.2.6-20050316/elementtree . >> python2.4 test-markdown.py >> > > Or for any platform: > easy_install http://splyer.com/markdown2.0-alpha.tar.gz > easy_install elementtree > It occurs to me that we do not have an INSTALL file in the distribution. Perhaps we should add one and write up the install procedure there. Then, when we release, we can just copy that over to the wiki as well. -- ---- Waylan Limberg wa...@gm... |
|
From: Yuri T. <qar...@gm...> - 2008-08-08 00:41:14
|
> Or for any platform: > easy_install http://splyer.com/markdown2.0-alpha.tar.gz > easy_install elementtree That too, though if you are limited to python2.3, chances are you don't have easy_install pre-installed. :) > What about AND_SUBSTITUTE ? I use it in some places instead of "&", now > it's: > AND_SUBSTITUTE = unichr(2) + unichr(4) + unichr(3) > is it ok ? Just for the sake of consistency, I would make it STX+"amp"+ETX. And I would call it AMPERSAND_SUBSTITUTE or AMP_SUBSTITUTE, since AND_SUBSTITUTE can mean too many things. Also, can you add more comments to the code? (I mean especially the parts that you changed, though you are welcome to comment old code as well.) Also, we had that discussion of recursion before. I am in principle all for getting rid of recursion as Waylan was suggesting, but I think considering the time constraints, perhaps it would be more practical to cap recursion by simply breaking the input into chunks. This needs to be done with a little bit of thought so that we don't break lists, etc. into multiple chunks. However, I think it will be much easier than trying to rewrite the current _processSection logic and it should get us the same benefits in terms of performance. - yuri -- http://sputnik.freewisdom.org/ |
|
From: Artem Y. <ne...@gm...> - 2008-08-09 00:13:30
|
Yuri Takhteyev wrote: >> Or for any platform: >> easy_install http://splyer.com/markdown2.0-alpha.tar.gz >> easy_install elementtree >> > > That too, though if you are limited to python2.3, chances are you > don't have easy_install pre-installed. :) > Yep, forgot about it. For Windows it'll be quite simple, there are official binary installers. Also a lot of Linux distributions includes ElementTree in the repository. For instance for Debian/Ubuntu it'll be: apt-get install python-elementtree for BSD systems, i.e FreeBSD: cd /usr/ports/devel/py-elementtree; make install clean Fedora Core (and I suppose Red Hat too): yum install python-elementtree > >> What about AND_SUBSTITUTE ? I use it in some places instead of "&", now >> it's: >> AND_SUBSTITUTE = unichr(2) + unichr(4) + unichr(3) >> is it ok ? >> > > Just for the sake of consistency, I would make it STX+"amp"+ETX. And > I would call it AMPERSAND_SUBSTITUTE or AMP_SUBSTITUTE, since > AND_SUBSTITUTE can mean too many things. > Good idea, changed to AMP_SUBSTITUTE = STX+"amp"+ETX > Also, can you add more comments to the code? (I mean especially the > parts that you changed, though you are welcome to comment old code as > well.) > Added some more comments, and revisioned old ones, maybe later add some more. > Also, we had that discussion of recursion before. I am in principle > all for getting rid of recursion as Waylan was suggesting, but I think > considering the time constraints, perhaps it would be more practical > to cap recursion by simply breaking the input into chunks. This needs > to be done with a little bit of thought so that we don't break lists, > etc. into multiple chunks. However, I think it will be much easier > than trying to rewrite the current _processSection logic and it should > get us the same benefits in terms of performance. > If time permits, I'll try to do it extendable, if not - just get rid of recursion. |
|
From: Yuri T. <qar...@gm...> - 2008-08-09 00:30:35
|
> For instance for Debian/Ubuntu it'll be: > apt-get install python-elementtree > > for BSD systems, i.e FreeBSD: > cd /usr/ports/devel/py-elementtree; make install clean > > Fedora Core (and I suppose Red Hat too): > yum install python-elementtree This is all good if you have root access. However, if you want to use python markdown for a website running on shared hosting, then there is a good chance that you have limited access, so those methods are out of the question. I know _I_ don't have root access to the machine where the python markdown wiki is running. And believe it or not, some people don't even have shell access to their hosts - only ftp. Last year I had to try install mediawiki via ftp. Don't get me started on this. So, it's good to document all of those methods, but we also need to keep in mind the user without root access. - yuri -- http://sputnik.freewisdom.org/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X