python-markdown-discuss — A general purpose discussion list

Re: [Python-markdown-discuss] XHTML or HTML?

[Waylan L. <wa...@gm...>]

On Thu, Jan 8, 2009 at 9:47 AM, Eric Abrahamsen <gi...@gm...> wrote:
>
> On Jan 8, 2009, at 10:10 PM, Waylan Limberg wrote:
>
>> Of course, there is the lxml package with various helpful html tools.
>> However, being a rather difficult to install C library, we didn't want
>> to make that a dependency of Python-Markdown. That said, there isn't
>> any reason someone couldn't use lxml to write an extension.
>
> Can you give a bit of a hint in this direction – I would also much prefer to
> output plain html, and I have the good fortune of having lxml installed on
> my servers (ain't webfaction grand?). Lots of things are changing for
> python-markdown 2.0, will the post-processors still work the same? I assume
> that this currently does the trick (haven't tried it yet):
>

Yeah Webfaction is great. Unfortunately, not everyone offers such a
great service. We had talked at one point of having markdown import
lxml rather than ElementTree if it was available. Don't remember why
did decided not to. The list archives would answer that. However, if
you could provide a patch that works - I'll likely commit it.

Now to answer your question; the extension API is fully documented [1]
in the docs dir of the git repo.

[1]: http://gitorious.org/projects/python-markdown/repos/mainline/blobs/8f3f5a9071631b22e41d3894c236416fef4280b7/docs/writing_extensions.txt



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] XHTML or HTML?

[Waylan L. <wa...@gm...>]

Yes, Python-Markdown outputs XHTML. In fact, in the soon to be
released 2.0 we are using ElementTree to build the XHTML. As
ElementTree is a rather strict XML tool, the output is always
guaranteed to be valid XML and, thus, assuming no bugs (such as
invalid tags or improper nesting), valid XHTML. Unfortunately, I am
not aware of any tool that converts an ElementTree object to HTML4. If
anybody else is, I'll happily add it as an option.

Of course, there is the lxml package with various helpful html tools.
However, being a rather difficult to install C library, we didn't want
to make that a dependency of Python-Markdown. That said, there isn't
any reason someone couldn't use lxml to write an extension.

In fact, I recently wrote an extension which uses Tidy to clean up
ElementTree's poorly done whitespace (the insignificant kind) and
convert between XHTML and HTML. But, again, a C library has to be
installed for it to work. That's not an option on most shared hosting
servers - where python-markdown is most likely used.

On Thu, Jan 8, 2009 at 7:54 AM, tchomby <tc...@go...> wrote:
> What standard(s) does python-markdown's output conform to, XHTML 1.0,
> XHTML 1.1, HTML 4.01, etc.?
>
> I know that the original perl markdown produces valid XHTML by default
> or HTML (with the --html4tags option). Python-markdown doesn't seem to
> have the --html4tags option, so is it XHTML then?
>
> Thanks
>
> ------------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It is the best place to buy or sell services for
> just about anything Open Source.
> http://p.sf.net/sfu/Xq1LFB
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
----
Waylan Limberg
wa...@gm...

[Python-markdown-discuss] XHTML or HTML?

[tchomby <tc...@go...>]

What standard(s) does python-markdown's output conform to, XHTML 1.0,
XHTML 1.1, HTML 4.01, etc.?

I know that the original perl markdown produces valid XHTML by default
or HTML (with the --html4tags option). Python-markdown doesn't seem to
have the --html4tags option, so is it XHTML then?

Thanks

Re: [Python-markdown-discuss] Email-style blockquote formatter?

[Yuri T. <qar...@gm...>]

> For additional perfection, I'd like to tag the attribution line in front
> of a quote block with some special class so that I can CSS it up to look
> like an attribution instead of a random paragraph (i.e. italics, and no
> excessive whitespace between the two). But I'll download version 2
> before thinking further about that.

We try to stick close to standard markdown by default, and this
wouldn't be the standard markdown behavior. However, what you want to
do could be easily done with an extension. You should have a look at
the (new) extension API. The purpose of the extension API is precisely
to allow people to customize markdown while the core markdown can stay
compliant with other implementations.

(Sorry about the slow response - I was traveling.)

  - yuri

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] Email-style blockquote formatter?

[Matthias U. <sm...@sm...>]

Hi,

Waylan Limberg:
> Well, the implementations don't get it wrong, but they do output
> something different than what I suspect Mattias was expecting. Sorry,
> that is what I was trying to say. Bad choice of words.
> 
No problem.

So I suspect that a simple "insert a blank line whenever the indent
level changes, and insist on one space between the angles" filter should do
the right thing. Thanks, that was easy. ;-)

For additional perfection, I'd like to tag the attribution line in front
of a quote block with some special class so that I can CSS it up to look
like an attribution instead of a random paragraph (i.e. italics, and no
excessive whitespace between the two). But I'll download version 2
before thinking further about that.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  sm...@sm...
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
v4sw7$Yhw6+8ln7ma7u7L!wl7DUi2e6t3TMWb8HAGen6g3a4s6Mr1p-3/-6 hackerkey.com
 - -
Data, n.:
	An accrual of straws on the backs of theories.

Re: [Python-markdown-discuss] Email-style blockquote formatter?

[Waylan L. <wa...@gm...>]

On Wed, Dec 24, 2008 at 6:36 PM, Waylan Limberg <wa...@gm...> wrote:
> On Wed, Dec 24, 2008 at 4:36 PM, Yuri Takhteyev <qar...@gm...> wrote:
>> Actually, it's the lack of spaces after blockquotes. If you change
>> Matthias's example to make sure there is a space after every angle
>> bracket, it works quite reasonably.
>
> I disagree. The "whatever" and "right" lines in Mathias' example
> should step out of the second level and according to babelmark, every
> implementation except Maruku gets that wrong by including everything
> past the first line of the second level in the second level.

Well, the implementations don't get it wrong, but they do output
something different than what I suspect Mattias was expecting. Sorry,
that is what I was trying to say. Bad choice of words.



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Email-style blockquote formatter?

[Waylan L. <wa...@gm...>]

On Wed, Dec 24, 2008 at 4:36 PM, Yuri Takhteyev <qar...@gm...> wrote:
> Actually, it's the lack of spaces after blockquotes. If you change
> Matthias's example to make sure there is a space after every angle
> bracket, it works quite reasonably.

I disagree. The "whatever" and "right" lines in Mathias' example
should step out of the second level and according to babelmark, every
implementation except Maruku gets that wrong by including everything
past the first line of the second level in the second level. The only
way to avoid that is with blank lines. So the issue (not specific to
python) is blank lines more that spaces after >s.

To take this further it occurred to me after my last response, that
the last line of Mattias' example was not meant to be part of any
blockquote, but a response to the first level blockquote. Per the
syntax, the only way that will work is with a blank line.

Compare:

    > right
    wrong

to this:

    > rigth

    wrong

The syntax is very clear that the first example above must result in:

    <blockquote>
      <p>right
      wrong</p>
    </blockquote>

While I suspect the desired result was this (which is obtained by the
second example above):

    <blockquote>
      <p>right</p>
    </blockquote>

    <p>wrong</p>

So yeah, the issue is blank lines. However, this is *not* a bug in
markdown, but a feature. Yes it does restrict the author a little, but
it is necessary given the syntax rules as they are written.

> I think this is a bug, actually, because there is no reason we should
> require that space, and Matthias's example does work many (though not
> all) other implementations.

Personally, I prefer requiring the space - but then I always did
prefer stricter whitespace in the syntax than most people. Whatever.





-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Email-style blockquote formatter?

[Yuri T. <qar...@gm...>]

Actually, it's the lack of spaces after blockquotes. If you change
Matthias's example to make sure there is a space after every angle
bracket, it works quite reasonably.

I think this is a bug, actually, because there is no reason we should
require that space, and Matthias's example does work many (though not
all) other implementations.

It looks like a small change makes the example work, though it breaks
one of our tests.  Committed the change for now (as 8f3f5a9) and will
try to look into what's the deal with the test.

  - yuri

On Wed, Dec 24, 2008 at 7:07 PM, Waylan Limberg <wa...@gm...> wrote:
> Actually markdown does blockquotes out of the box. The email style is
> the markdown syntax for blockquotes [1] with some restrictions.
>
> The reason your example doesn't work as expected is that markdown
> *insists* on a blank line between each block-level element. So either
> of the following will give you your expected output:
>
>    foo wrote:
>
>    > bar wrote:
>    >
>    > > baz
>    >
>    > whatever
>    >
>    > > quux
>    >
>    > right
>    > wrong
>
> Or:
>
>    foo wrote:
>
>    > bar wrote:
>
>    > > baz
>
>    > whatever
>
>    > > quux
>
>    > right
>    wrong
>
> Note that the double quoted lines have a space between the >s. Again,
> this is a requirement of the markdown syntax. To play with it, I
> suggest babelmark [2].
>
> So to answer your question directly, no, there is no extension as the
> existing syntax is good enough for most (all?) users. However, if you
> want to tweak the existing behavior, then you are welcome to write
> your own extension. I suggest looking at the code on gitorious [3]
> which will be released as 2.0 soonish. It's much easier to alter the
> core than in 1.7. The docs [4] should help you out with that. Just be
> aware that until 2.0 is released, the API is subject to change -
> although I don't anticipate much change.
>
> [1]: http://daringfireball.net/projects/markdown/syntax#blockquote
> [2]: http://tinyurl.com/9xgjh3
> [3]: http://gitorious.org/projects/python-markdown/repos/mainline
> [4]: http://gitorious.org/projects/python-markdown/repos/mainline/blobs/master/docs/writing_extensions.txt
>
> On Wed, Dec 24, 2008 at 3:31 PM, Matthias Urlichs <sm...@sm...> wrote:
>> Hi,
>>
>> Is there an extension for email-style quoting, so that text like ...
>>
>> foo wrote:
>>> bar wrote:
>>>> baz
>>> whatever
>>>> quux
>>> right
>> wrong
>>
>> ... looks reasonably sane (i.e. nested blockquote tags, ideally with
>> support for RFC 2646)?
>>
>> Pointers appreciated.
>>
>> --
>> Matthias Urlichs  |  {M:U} IT Design @ m-u-it.de  |   sm...@sm...
>> Disclaimer: Das Zitat wurde zufällig ausgewählt.  |   http://smurf.noris.de
>>  - -
>> Gerade der Freie sucht den Schein der Freiheit am wenigsten.
>>                -- Jean Paul
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Python-markdown-discuss mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>
>
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
> ------------------------------------------------------------------------------
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] Email-style blockquote formatter?

[Waylan L. <wa...@gm...>]

Actually markdown does blockquotes out of the box. The email style is
the markdown syntax for blockquotes [1] with some restrictions.

The reason your example doesn't work as expected is that markdown
*insists* on a blank line between each block-level element. So either
of the following will give you your expected output:

    foo wrote:

    > bar wrote:
    >
    > > baz
    >
    > whatever
    >
    > > quux
    >
    > right
    > wrong

Or:

    foo wrote:

    > bar wrote:

    > > baz

    > whatever

    > > quux

    > right
    wrong

Note that the double quoted lines have a space between the >s. Again,
this is a requirement of the markdown syntax. To play with it, I
suggest babelmark [2].

So to answer your question directly, no, there is no extension as the
existing syntax is good enough for most (all?) users. However, if you
want to tweak the existing behavior, then you are welcome to write
your own extension. I suggest looking at the code on gitorious [3]
which will be released as 2.0 soonish. It's much easier to alter the
core than in 1.7. The docs [4] should help you out with that. Just be
aware that until 2.0 is released, the API is subject to change -
although I don't anticipate much change.

[1]: http://daringfireball.net/projects/markdown/syntax#blockquote
[2]: http://tinyurl.com/9xgjh3
[3]: http://gitorious.org/projects/python-markdown/repos/mainline
[4]: http://gitorious.org/projects/python-markdown/repos/mainline/blobs/master/docs/writing_extensions.txt

On Wed, Dec 24, 2008 at 3:31 PM, Matthias Urlichs <sm...@sm...> wrote:
> Hi,
>
> Is there an extension for email-style quoting, so that text like ...
>
> foo wrote:
>> bar wrote:
>>> baz
>> whatever
>>> quux
>> right
> wrong
>
> ... looks reasonably sane (i.e. nested blockquote tags, ideally with
> support for RFC 2646)?
>
> Pointers appreciated.
>
> --
> Matthias Urlichs  |  {M:U} IT Design @ m-u-it.de  |   sm...@sm...
> Disclaimer: Das Zitat wurde zufällig ausgewählt.  |   http://smurf.noris.de
>  - -
> Gerade der Freie sucht den Schein der Freiheit am wenigsten.
>                -- Jean Paul
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
----
Waylan Limberg
wa...@gm...

[Python-markdown-discuss] Email-style blockquote formatter?

[Matthias U. <sm...@sm...>]

Hi,

Is there an extension for email-style quoting, so that text like ...

foo wrote:
> bar wrote:
>> baz
> whatever
>> quux
> right
wrong

... looks reasonably sane (i.e. nested blockquote tags, ideally with
support for RFC 2646)?

Pointers appreciated.

-- 
Matthias Urlichs  |  {M:U} IT Design @ m-u-it.de  |   sm...@sm...
Disclaimer: Das Zitat wurde zufällig ausgewählt.  |   http://smurf.noris.de
 - -
Gerade der Freie sucht den Schein der Freiheit am wenigsten.
		-- Jean Paul

[Python-markdown-discuss] Announcing HTML Tidy Extension

[Waylan L. <wa...@gm...>]

I am please to announce that I'm  releasing a new extension that wraps
HTML Tidy[1] using the µTidylib [2] python wrapper. Not only does this
give the option for prettier output (indentation) but it will output
HTML or XHTML painlessly. In fact, any options [3] supported by HTML
Tidy can be passed into the extension as configs.

Both HTML Tidy and µTidylib will need to installed on your system for
this to work.

It *will* munge (and may choke on) raw html.

A few options that may be useful to many:

* output_xhtml: Turns xhtml output on or off. Defaults to 1/on.
* indent: Turns indent on or off (use auto for best output). Defaults to 0/off.
* show_body_only: Turns addition of <html>, <head> and <body> tags
on/off. Defaults to 0/off.

Note that the defaults most closely mimic python-markdown's default
behavior, only slitly improving on the etree prettify method. However,
the options are endless for how this could be used.

So to output HTML rather than XHTML (note the ``<hr>`` rather than ``<hr />``):

    >>> markdown.markdown("foo\n***\nbar", ["html_tidy(output_xhtml=0)"])
    u'<p>foo</p>\n<hr>\n<p>bar</p>'

The extension is attached for review. My question is: Is this
something we want packaged with markdown or should I keep it as a
separate library?

[1]: http://tidy.sourceforge.net/
[2]: http://utidylib.berlios.de/
[3]: http://tidy.sourceforge.net/docs/quickref.html

-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Getting rid of stash and postprocessing

[Neale P. <ne...@wo...>]

Hi Yuri

Truly this isn't a trivial change on my part, and applying it to code
that's since been refactored wouldn't be easy.  I'm glad you see where I
was trying to go with this and that you think this is useful work.

If you guys are near a major release I'd wait until after the release to
try and merge in my things, unless there's some great demand for it.

Glad all that work wasn't for nothing,

Neale

Re: [Python-markdown-discuss] Getting rid of stash and postprocessing

[Yuri T. <qar...@gm...>]

Thanks. Our code has gone through a serious refactoring, so applying
the changes won't be trivial, but I'll try to see which ones would
make sense to apply manually. Most of the changes make sense, and the
general idea for handing HTML is a good one, I think. Perhaps to make
this work we would need to change HtmlPreprocessor from a preprocessor
to a blockprocessor and then use AtomicString as you suggested in your
last commit. With a little more variation this would also give us a
good way to process markdown inside block-level tags like
MarkdownExtra does.

Not sure if we should do this for 2.0, though.

  - yuri

On Mon, Dec 8, 2008 at 1:54 PM, Neale Pickett <ne...@wo...> wrote:
> A while ago, I guess around November, I began working on some changes to
> markdown.py that would completely eliminate the need for regular
> expressions, or searching through a string for patterns to be replaced
> with other text.
>
> I was mostly successful.  I got rid of the Stash concept completely, as
> well as postprocessing.  The change resulted in markdown.py being 260
> lines shorter, and although I didn't time it I'm certain my changes
> result in quicker run times.
>
> I had intended to clean it up so that it passed all the included tests
> and then announce it to the list, but around October I started playing
> around with ikiwiki.  I liked it so much that I dropped my wiki project,
> and therefore quit working on the python markdown implementation.
>
> If anybody's interested in what I've done, you can check out my git
> project:
>
>    http://woozle.org/~neale/gitweb.cgi?p=py-markdown
>
> or you can pull in my git tree:
>
>    http://woozle.org/~neale/projects/py-markdown/
>
> I'm happy to answer questions but I don't think I have it in my to do
> any more work on things.  Hopefully this is of some use to the project.
>
> Neale
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
http://sputnik.freewisdom.org/

[Python-markdown-discuss] Getting rid of stash and postprocessing

[Neale P. <ne...@wo...>]

A while ago, I guess around November, I began working on some changes to
markdown.py that would completely eliminate the need for regular
expressions, or searching through a string for patterns to be replaced
with other text.

I was mostly successful.  I got rid of the Stash concept completely, as
well as postprocessing.  The change resulted in markdown.py being 260
lines shorter, and although I didn't time it I'm certain my changes
result in quicker run times.

I had intended to clean it up so that it passed all the included tests
and then announce it to the list, but around October I started playing
around with ikiwiki.  I liked it so much that I dropped my wiki project,
and therefore quit working on the python markdown implementation.

If anybody's interested in what I've done, you can check out my git
project:

    http://woozle.org/~neale/gitweb.cgi?p=py-markdown

or you can pull in my git tree:

    http://woozle.org/~neale/projects/py-markdown/

I'm happy to answer questions but I don't think I have it in my to do
any more work on things.  Hopefully this is of some use to the project.

Neale

Re: [Python-markdown-discuss] Python 3.0

[Waylan L. <wa...@gm...>]

> I am getting one small anomaly in 2.3 & 2.4 with the "uche" test,
> although it appears to only be insignificant whitespace

Figured this one out. I appears that the brand new versions of
ElementTree (newer than what ships with 2.5, 2.6 & 3.0) I installed
for 2.3 & 2.4 is encoding the line break in that test (as ``
``)
while older versions left it as-is (``\n``).

As those linebreaks are insignificant, I am just removing them.

> Hmm, perhaps we should wrap that test
> in a conditional and only run it when those conditions (Pygments and
> version > 3.0) are met.

I've also committed a somewhat hacky patch for this. It occurs to me
that perhaps the tester should be able to do this, but the API is not
so clear. We could pass a list of dependant packages to the
test_directory method. Something like:

    tester.test_directory("tests/extensions-x-codehilite", depends=["pygments"])

Then the tester would only run the test if it can successfully import
each package in the list. Perhaps a message should be printed that the
test was skipped and why.

Any thoughts?

-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Python 3.0

[Waylan L. <wa...@gm...>]

On Mon, Dec 8, 2008 at 4:52 AM, Yuri Takhteyev <qar...@gm...> wrote:
> Thanks. What about the extensions-x-codehilite/code.txt test. I am
> getting a diff on this one. Do you?

I did until I installed Pygments for each version of Python, which
that extension depends on. Note that the extension does have a
fallback if Pygments is not available, but, obviously, the output is
different (not highlighted) so the test fails. Pygments has not yet
been released for 3.0 and I'm not about to try running 2to3 on it, so
it will continue to fail there. Hmm, perhaps we should wrap that test
in a conditional and only run it when those conditions (Pygments and
version > 3.0) are met.


-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Python 3.0

[Yuri T. <qar...@gm...>]

Thanks. What about the extensions-x-codehilite/code.txt test. I am
getting a diff on this one. Do you?

Does anyone have any other tests to contribute?

- yuri

On Sun, Dec 7, 2008 at 9:34 AM, Waylan Limberg <wa...@gm...> wrote:
> On Sun, Dec 7, 2008 at 3:52 AM, John Szakmeister <jo...@sz...> wrote:
>> On Sat, Dec 6, 2008 at 10:38 PM, Waylan Limberg <wa...@gm...> wrote:
>> [snip]
>>> Strangely, I don't see a "para-with-hr" test anywhere. Is this perhaps
>>> some old test you never committed and it isn't passing after some
>>> recent changes?
>>
>> It's in tests/misc.  That's one I submitted to you guys a couple months ago.
>>
>
> Thanks John, and Yuri for commiting it. However, the test was failing
> because the *test* was wrong, not the code. That was not valid html. A
> <hr> is a block level element and no block level elements are allowed
> in <p>s. I have updated the test and it passes. In other words the
> code was correct. I thought I had tested for that when refactoring the
> core - which explains my confusion about it failing.
>
> Fyi Yuri, I also fixed your missing imports in markdown.py after you
> rearranged the logger.
>
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>



-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] Python 3.0

[John S. <jo...@sz...>]

On Sun, Dec 7, 2008 at 12:34 PM, Waylan Limberg <wa...@gm...> wrote:
[snip]
> Thanks John, and Yuri for commiting it. However, the test was failing
> because the *test* was wrong, not the code. That was not valid html. A
> <hr> is a block level element and no block level elements are allowed
> in <p>s. I have updated the test and it passes. In other words the
> code was correct. I thought I had tested for that when refactoring the
> core - which explains my confusion about it failing.

Heh.  I was certain I looked that up... especially since I found
confusing documentation on whether it was a block-level or span-level
tag.  Sorry for the broken test.

-John

Re: [Python-markdown-discuss] Python 3.0

[Waylan L. <wa...@gm...>]

On Sun, Dec 7, 2008 at 3:52 AM, John Szakmeister <jo...@sz...> wrote:
> On Sat, Dec 6, 2008 at 10:38 PM, Waylan Limberg <wa...@gm...> wrote:
> [snip]
>> Strangely, I don't see a "para-with-hr" test anywhere. Is this perhaps
>> some old test you never committed and it isn't passing after some
>> recent changes?
>
> It's in tests/misc.  That's one I submitted to you guys a couple months ago.
>

Thanks John, and Yuri for commiting it. However, the test was failing
because the *test* was wrong, not the code. That was not valid html. A
<hr> is a block level element and no block level elements are allowed
in <p>s. I have updated the test and it passes. In other words the
code was correct. I thought I had tested for that when refactoring the
core - which explains my confusion about it failing.

Fyi Yuri, I also fixed your missing imports in markdown.py after you
rearranged the logger.



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Python 3.0

[John S. <jo...@sz...>]

On Sat, Dec 6, 2008 at 10:38 PM, Waylan Limberg <wa...@gm...> wrote:
[snip]
> Strangely, I don't see a "para-with-hr" test anywhere. Is this perhaps
> some old test you never committed and it isn't passing after some
> recent changes?

It's in tests/misc.  That's one I submitted to you guys a couple months ago.

-John

Re: [Python-markdown-discuss] Python 3.0

[Waylan L. <wa...@gm...>]

On Thu, Dec 4, 2008 at 11:21 PM, Yuri Takhteyev <qar...@gm...> wrote:
>> Hmm, it's not failing for me in 2.5. I haven't installed 2.6 yet. My
>> understanding is that that is where we should be testing before
>> running 2to3. I'll have to investigate further.
>
> It fails for me in 2.5.  BTW, it looks like we (actually, probably I)
> broke 2.4 compatibility at some point.
>

Ok, I got 2.6 and 3.0 installed today. All tests are passing for me in
2.5 & 2.6 (including extensions) and all non-extension tests are
passing in 3.0. I should also note that the doctests in extensions
(run regression-tests.py) that have them *are* passing in 3.0 (after
removing the u from string output in the tests), so I suspect it's a
problem with test-markdown.py.

I am getting one small anomaly in 2.3 & 2.4 with the "uche" test,
although it appears to only be insignificant whitespace. The
regression tests run fine except for doctests for the 'headerid' and
'wikilinks' extensions in 2.3 - although the syntax tests are passing
for both.

Strangely, I don't see a "para-with-hr" test anywhere. Is this perhaps
some old test you never committed and it isn't passing after some
recent changes?


-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Python 3.0

[Waylan L. <wa...@gm...>]

On Thu, Dec 4, 2008 at 11:21 PM, Yuri Takhteyev <qar...@gm...> wrote:
[snip]
> (Again, we can drop 2.3 at some point, if there is a good reason.)
[snip]

Fyi, Django is currently talking about dropping 2.3 support [1]. It
hasn't been decided conclusively yet with some devs on either side of
the fence, but they're looking at it. I'll report back on this when I
know more. Obviously, we should not do so just because some other
package does, but the Django team is very attune to the community at
large and a nice way for a small project like ours to gauge these
sorts of things. There's some interesting points both for and against
in that discussion.

I have to wonder if the jump to 2.0 is enough for us to warrant
dropping 2.3 support given other, larger projects are looking at doing
the same. After all, having a major release (x.0) is a strange place
to start issuing depreciation warnings (as some suggest for Django)
for 2.3 specific code that will be removed in x.1. That seems silly to
me. If we're going to do it, now is as good a time as any. I suppose
we'll have to see how things play out for others.

[1]: http://groups.google.com/group/django-developers/browse_thread/thread/dcf70c736c204594

-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Python 3.0

[Waylan L. <wa...@gm...>]

On Thu, Dec 4, 2008 at 2:42 PM, Yuri Takhteyev <qar...@gm...> wrote:
>
> After that you need to make one change manually, in markdown/inlinepatterns.py:
>
> -import htmlentitydefs
> +from html import entities as htmlentitydefs
>

Hmm, on further thought and a little research, this is a known change
[1], so shouldn't 2to3 be making this change for us? If not, is that a
bug in 2to3? I did a search and haven't found it reported anywhere.

[1]: http://www.python.org/dev/peps/pep-3108/#id62

-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Python 3.0

[Yuri T. <qar...@gm...>]

> Seeing the code won't run as-is (the user still needs to run 2to3) in
> 3.0, I do *not* think we should be adding this version check.
> Obviously, if we are supporting 3.0 (through 2to3) that should be
> documented and a note about this could be made there. I suppose a
> comment in the source could help as well.

When we make a release, the user should be able to download a py3k
version and just install it.  We just shouldn't keep the py3k version
in our git tree. Our git tree should have 3.0-friendly code that runs
as is with python 2.3, 2.4, 2.5 and 2.6. (Again, we can drop 2.3 at
some point, if there is a good reason.) "3.0-friendly" means that if
you run it through 2to3, it would work with py3k without further
changes. People who want to contribute patches should always do so
against the 2.x version. When we make a release, however, we can
publish two versions simultaneously, from the same code base:

git -> zip -> "markdown-2.0.zip"
git -> 2to3 -> zip -> "markdown-2.0-py3k.zip"

We don't _have_ to do this for 2.0, since at this point people who
want to run py3k will know how to run 2to3, but we'll have to get to
doing this eventually and we might as well start now. (It doesn't look
like we have to do much additional work for this.)

> Hmm, it's not failing for me in 2.5. I haven't installed 2.6 yet. My
> understanding is that that is where we should be testing before
> running 2to3. I'll have to investigate further.

It fails for me in 2.5.  BTW, it looks like we (actually, probably I)
broke 2.4 compatibility at some point.

- yuri

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] Python 3.0

[Waylan L. <wa...@gm...>]

On Thu, Dec 4, 2008 at 5:50 PM, Yuri Takhteyev <qar...@gm...> wrote:
>> Nice :) What about adding version check ? Something like this:
>>
>>     if sys.version >= "3.0":
>>         from html import entities as htmlentitydefs
>>     else:
>>         import htmlentitydefs

Seeing the code won't run as-is (the user still needs to run 2to3) in
3.0, I do *not* think we should be adding this version check.
Obviously, if we are supporting 3.0 (through 2to3) that should be
documented and a note about this could be made there. I suppose a
comment in the source could help as well.

    import htmlentitydefs
    # For Python 3.0+ comment above line and uncomment line below
    # from html import entities as htmlentitydefs

>
> We shouldn't _have_ to do that, but works for now. I also realized
> that "para-with-hr" already fails,

Hmm, it's not failing for me in 2.5. I haven't installed 2.6 yet. My
understanding is that that is where we should be testing before
running 2to3. I'll have to investigate further.

> so the new problem is just limited
> to test-markdown.py. (Test-markdown.py fails in python 3.0 when it
> tries to save diff for a failed test.)
>
> So, with the most recent commit (cd73ef7), all you have to do is run
> 2to3 on "markdown", "markdown.py" and (optionally) "test-markdown.py".
>

Cool!



-- 
----
Waylan Limberg
wa...@gm...