Menu
▾
▴
python-markdown-discuss
|
From: tchomby <tc...@go...> - 2009-01-08 12:54:59
|
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 |
|
From: Waylan L. <wa...@gm...> - 2009-01-08 14:10:28
|
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... |
|
From: Waylan L. <wa...@gm...> - 2009-01-08 16:23:53
|
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... |
|
From: Waylan L. <wa...@gm...> - 2009-01-10 19:27:16
|
On Sat, Jan 10, 2009 at 7:32 AM, Eric Abrahamsen <gi...@gm...> wrote:
>> 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.
>
> Looking through the mailing list archives, it looks like things stopped at
> "yes, that would be a good idea". As far as I can tell there wasn't any
> further action. I tried adding lxml to the import cascade in
> etree_loader.py, and it imports okay, but fails tests (I can provide more
> details if necessary).
Yeah, I seem to recall there being some differences between the two. I
wasn't the one who wrote that code, so the details aren't as clear to
me. Perhaps the final decision was made by the core devs off list.
> Then I realized that the lxml etree implementation is
> essentially unrelated to the lxml.html.xhtml_to_html function. Before
> messing with things further, I want to make sure this the right way: I'm
> thinking of adding a "html" keyword argument to the Markdown class
> definition. If it's set to true we try to import lxml.html.xhtml_to_html. If
> that fails we log a warning and then ignore it. if it succeeds, run
> xhtml_to_html right after the treeprocessors (I guess, would have to
> experiment). Does this seem generally sound?
The general idea is good, except that all xhtml_to_html does (afaict)
is remove the xml namespace for each element - which we never set to
begin with. What we need is something to convert from ``<br />`` to
``<br>`` and the like. The only way I'm aware of would be to build up
the tree with lxml.html from the start. But that would require
everyone have lxml installed or we maintain 2 versions of the code.
Neither is a practical option.
However, I would love to be proved wrong on that assessment.
As an aside, for a quick-fix, you could write a postprocessor which
simply does something like ``text.replace(" />", ">")``. However,
there are a few edge cases where that won't quite cut it. Therefore,
we don't offer it as a builtin option. However, it may be good enough
for many peoples needs.
--
----
Waylan Limberg
wa...@gm...
|
|
From: Artem Y. <se...@sp...> - 2009-01-11 00:32:59
|
On Sat, Jan 10, 2009 at 11:27 PM, Waylan Limberg <wa...@gm...> wrote:
> On Sat, Jan 10, 2009 at 7:32 AM, Eric Abrahamsen <gi...@gm...> wrote:
> >> 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.
> >
> > Looking through the mailing list archives, it looks like things stopped
> at
> > "yes, that would be a good idea". As far as I can tell there wasn't any
> > further action. I tried adding lxml to the import cascade in
> > etree_loader.py, and it imports okay, but fails tests (I can provide more
> > details if necessary).
>
> Yeah, I seem to recall there being some differences between the two. I
> wasn't the one who wrote that code, so the details aren't as clear to
> me. Perhaps the final decision was made by the core devs off list.
As far as I remember, there were some problems with several tests, and no
great performance boost in compare with cElementTree(only 4%), so we decided
to go with standard cElementTree/ElementTree.
Eric, If you want HTML output you can use ElementTree 1.3 [1]
tree.write("out.html", method="html")
[1]: http://effbot.org/zone/elementtree-13-intro.htm
>
>
> > Then I realized that the lxml etree implementation is
> > essentially unrelated to the lxml.html.xhtml_to_html function. Before
> > messing with things further, I want to make sure this the right way: I'm
> > thinking of adding a "html" keyword argument to the Markdown class
> > definition. If it's set to true we try to import lxml.html.xhtml_to_html.
> If
> > that fails we log a warning and then ignore it. if it succeeds, run
> > xhtml_to_html right after the treeprocessors (I guess, would have to
> > experiment). Does this seem generally sound?
>
> The general idea is good, except that all xhtml_to_html does (afaict)
> is remove the xml namespace for each element - which we never set to
> begin with. What we need is something to convert from ``<br />`` to
> ``<br>`` and the like. The only way I'm aware of would be to build up
> the tree with lxml.html from the start. But that would require
> everyone have lxml installed or we maintain 2 versions of the code.
> Neither is a practical option.
>
> However, I would love to be proved wrong on that assessment.
>
> As an aside, for a quick-fix, you could write a postprocessor which
> simply does something like ``text.replace(" />", ">")``. However,
> there are a few edge cases where that won't quite cut it. Therefore,
> we don't offer it as a builtin option. However, it may be good enough
> for many peoples needs.
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>
>
> ------------------------------------------------------------------------------
> 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
>
|
|
From: Waylan L. <wa...@gm...> - 2009-01-11 02:25:33
|
On Sat, Jan 10, 2009 at 5:54 PM, Artem Yunusov <se...@sp...> wrote:
>
>
> On Sat, Jan 10, 2009 at 11:27 PM, Waylan Limberg <wa...@gm...> wrote:
>>
>> On Sat, Jan 10, 2009 at 7:32 AM, Eric Abrahamsen <gi...@gm...> wrote:
>> >> 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.
>> >
>> > Looking through the mailing list archives, it looks like things stopped
>> > at
>> > "yes, that would be a good idea". As far as I can tell there wasn't any
>> > further action. I tried adding lxml to the import cascade in
>> > etree_loader.py, and it imports okay, but fails tests (I can provide
>> > more
>> > details if necessary).
>>
>> Yeah, I seem to recall there being some differences between the two. I
>> wasn't the one who wrote that code, so the details aren't as clear to
>> me. Perhaps the final decision was made by the core devs off list.
>
> As far as I remember, there were some problems with several tests, and no
> great performance boost in compare with cElementTree(only 4%), so we decided
> to go with standard cElementTree/ElementTree.
>
> Eric, If you want HTML output you can use ElementTree 1.3 [1]
>
> tree.write("out.html", method="html")
>
For the record, ET 1.3 is still in alpha and the docs specifically
state that the HTML API is still in flux, so I doubt we will be adding
that support to Python-Markdown for the time being. Perhaps in a
future release. However, reviewing their code may be a good first step
in developing a list of changes that need to be made through
text-replacement in a postprocessor. While not the best solution, it
is better than nothing.
--
----
Waylan Limberg
wa...@gm...
|
|
From: Waylan L. <wa...@gm...> - 2009-01-11 02:47:27
|
On Sat, Jan 10, 2009 at 9:25 PM, Waylan Limberg <wa...@gm...> wrote:
> On Sat, Jan 10, 2009 at 5:54 PM, Artem Yunusov <se...@sp...> wrote:
>>
>>
>> Eric, If you want HTML output you can use ElementTree 1.3 [1]
>>
>> tree.write("out.html", method="html")
>>
>
> For the record, ET 1.3 is still in alpha and the docs specifically
> state that the HTML API is still in flux, so I doubt we will be adding
> that support to Python-Markdown for the time being. Perhaps in a
> future release. However, reviewing their code may be a good first step
> in developing a list of changes that need to be made through
> text-replacement in a postprocessor. While not the best solution, it
> is better than nothing.
>
>
It occurs to me that, with Fredrik Lundh's permission and a proper
license and copyright notice, we could maintain and distribute a
(perhaps slightly modified) copy of the _serialize_html function from
ET 1.3. Then use that instead of tostring if the user requests html
output. I haven't actually tried it, so I don't know how well it will
work as I suspect it expects the other changes in ET 1.3, but it may
be worth exploring.
--
----
Waylan Limberg
wa...@gm...
|
|
From: Waylan L. <wa...@gm...> - 2009-01-27 15:23:59
|
On Tue, Jan 27, 2009 at 9:58 AM, Eric Abrahamsen <gi...@gm...> wrote: > > Hey there, I've finally got this working. I tried some clever stuff with > subclassing ElementTree, but it was impossible to make work given the > variety of ElementTrees we might be working with, so I went with the > brute-force method: copying large chunks of code out of etree1.3. I've now > got something that works as expected with Python 2.5.1 and cElementTree, and > also made some supporting tests. I have never used git before, and I'm > currently failing to add a branch to the mainline repository -- the > tutorials I'm reading are not doing the trick. Can you tell me simply how to > put this stuff online? I'm working on master, locally, and all my changes > are committed, but I don't know what to do next... > > One thing I don't have here is the ability to test this with the full range > of python/ElementTree version variations. If one of you have a full test > environment, that would be great, otherwise I can install a few more > versions of python on my development machine (something I'll need to do > sooner or later, anyway). Hope all this works out! Let me know what to do > next. > Well, you probably don't have commit access to the mainline repo. What you should do is create your own cloned repo on gitorious and push to that. Then we can review the code, pull it down and merge it into the mainline and push it back up. Or, you always could just create a patch and email it to me (and the list). Then I could review and apply the patch and push from there. Speaking of emailing to the list, I noticed you haven't been replying to the list - only me. I've been trying to add the list back in on my replies, but may have missed a few. We prefer to keep these discussions on the list for a few reasons: they are archived for later reference, and others have an opportunity to contribute etc. Could you try to remember to hit "reply to all" rather than "reply" in your email client? I realize we all forget sometimes and I don't mean to be whiny, but a helpful reminder is good sometimes. Btw, I have a full testing environment, so I can take care of that. For those that care, I recently documented how I set it up here: http://achinghead.com/archive/83/installing-multiple-versions-python/ -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Matthias U. <sm...@sm...> - 2009-01-28 06:03:14
|
Hi,
Waylan Limberg:
> One more question: Eric put the "output_format" keyword in the
> "convert" & "convertFromFile" methods, not the "__init__" method of
> the Markdown class. Do we want to set the format for the class (in
> "__init__") or per call to "convert". The current implementation
> allows easy output of both formats. However, I wonder if the more
> common usage is to always require a single format for multiple
> documents. If so, then it should be set on "__init__" instead. Any
> input?
>
s/instead/do both/.
My rationale for this is that I want an instance that's set up the way I
want to have it set up for the common case, and be able to override
the format for specific output formats. Think "HTML web site with
Atom feed", for example.
--
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
- -
All his life he has looked away... to the horizon, to the sky,
to the future. Never his mind on where he was, on what he was doing.
-- Yoda
|
|
From: Waylan L. <wa...@gm...> - 2009-01-28 15:30:30
|
On Wed, Jan 28, 2009 at 1:02 AM, Matthias Urlichs <sm...@sm...> wrote:
> Hi,
>
> Waylan Limberg:
>> Do we want to set the format for the class (in "__init__") or per call to "convert".
>>
> s/instead/do both/.
>
> My rationale for this is that I want an instance that's set up the way I
> want to have it set up for the common case, and be able to override
> the format for specific output formats. Think "HTML web site with
> Atom feed", for example.
>
Hi Matthias,
Thanks for your feedback.
Upon further thought, I had come to the same conclusion, more-or-less.
The fact is, when running multiple documents through a single instant
of the Markdown class, a user may already need to call other methods
on the instance (such as reset), so, if the "output_format" is a
property of the class, that can be changed between calls to
``convert`` if needed. I'm thinking of doing something like this:
md = Markdown(output_format="html4")
html = md.convert(some_text)
md.set_output_format("xhtml") # <-- note this line
xhtml = md.convert(some_text)
Now, I could just do ``md.output_format = "xhtml", but I think I'm
going to have the method actually assign the appropriate serializer as
a property of the class. Something like:
def set_output_format(self, format):
if format in ['html', 'html4']:
self.serializer = html4.tostring
if format in ['xhtml', 'xhtml1]:
self.serializer in etree.tostring
This way someone *could* override/replace the serializer with their
own (say html5) and output any format they wanted. Or, if due to
licensing issues, markdown gets distributed without the html4
serializer (by Debian for example), there's still an easy way for
someone to add their own etc.
Any thoughts on this approach?
Just to be clear, we would *not recommend* people replace the
serializer (as it may break existing extensions etc), but making it
possible adds one more layer of extendability. For example, someone
*might* write an extension which replaces the serializer and all
postprocessors for an output_format that it not anything like html
(pdf or latex come to mind). How easy or difficult it would be to
write such an extension, I don't know, but at least it would be
possible. That's more than can be said now.
--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
|
|
From: Waylan L. <wa...@gm...> - 2009-01-28 19:38:50
|
Bah, this message didn't get copied to the list. Here it is: ---------- Forwarded message ---------- From: Waylan Limberg <wa...@gm...> Date: Wed, Jan 28, 2009 at 2:36 PM Subject: Re: [Python-markdown-discuss] XHTML or HTML? To: Marco Pantaleoni <mar...@gm...> On Wed, Jan 28, 2009 at 2:02 PM, Marco Pantaleoni <mar...@gm...> wrote: >> >> Any thoughts on this approach? > > what about using a python property > (http://docs.python.org/library/functions.html#property)? > This would allow to use a method (which can be overridden in derived > classes), keeping the > simpler assignment syntax. > Well, we could, except that property requires new-style classes - which python-markdown does not use. To be honest, I don't know why. Perhaps for historical reasons. Although, I'm not aware of any reason holding us back from changing that. Yuri, do you have any input here? Btw, I just committed and pushed the changes (less the property). So we now support HTML4 output. :-) -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Yuri T. <qar...@gm...> - 2009-01-29 00:16:43
|
Is there any obvious benefit to not just adding output_format as a parameter to convert()? What do we gain with setting this as a field of the instance? > Well, we could, except that property requires new-style classes - > which python-markdown does not use. To be honest, I don't know why. > Perhaps for historical reasons. Although, I'm not aware of any reason > holding us back from changing that. No particularly good reason, considering that it's 2009 now. However, we should stick with what's available in 2.3. - yuri -- http://spu.tnik.org/ |
|
From: Waylan L. <wa...@gm...> - 2009-01-29 00:38:12
|
On Wed, Jan 28, 2009 at 7:16 PM, Yuri Takhteyev <qar...@gm...> wrote: > Is there any obvious benefit to not just adding output_format as a > parameter to convert()? What do we gain with setting this as a field > of the instance? More control and possibilities for extensions. As extensions are instance specific, an extension that relies on a specific output_format may need a new instance of the Markdown class to change the output_format. For example, an extension may add different postprocessors depending on the output format. The only clean way to do that is by keeping it instance specific. Granted, the above is all speculation. I don't have any specific extensions in mind that would need this right now. But after playing with the code both ways, this feels much cleaner Remember the markdown.markdown shortcut function does take output_format as a keyword, so this only effects the end user using the class directly. > >> Well, we could, except that property requires new-style classes - >> which python-markdown does not use. To be honest, I don't know why. >> Perhaps for historical reasons. Although, I'm not aware of any reason >> holding us back from changing that. > > No particularly good reason, considering that it's 2009 now. However, > we should stick with what's available in 2.3. According to the docs, new-style classes were introduced in 2.2. There were a few additional features added later, but those shouldn't affect us. Additionally, I have used new-style classes myself in 2.3 without incident. For that matter, so does Django which has always supported 2.3. -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Eric A. <gi...@gm...> - 2009-01-27 15:51:09
|
On Jan 27, 2009, at 11:23 PM, Waylan Limberg wrote: > On Tue, Jan 27, 2009 at 9:58 AM, Eric Abrahamsen <gi...@gm...> > wrote: >> >> Hey there, I've finally got this working. I tried some clever stuff >> with >> subclassing ElementTree, but it was impossible to make work given the >> variety of ElementTrees we might be working with, so I went with the >> brute-force method: copying large chunks of code out of etree1.3. >> I've now >> got something that works as expected with Python 2.5.1 and >> cElementTree, and >> also made some supporting tests. I have never used git before, and >> I'm >> currently failing to add a branch to the mainline repository -- the >> tutorials I'm reading are not doing the trick. Can you tell me >> simply how to >> put this stuff online? I'm working on master, locally, and all my >> changes >> are committed, but I don't know what to do next... >> >> One thing I don't have here is the ability to test this with the >> full range >> of python/ElementTree version variations. If one of you have a full >> test >> environment, that would be great, otherwise I can install a few more >> versions of python on my development machine (something I'll need >> to do >> sooner or later, anyway). Hope all this works out! Let me know what >> to do >> next. >> > > Well, you probably don't have commit access to the mainline repo. What > you should do is create your own cloned repo on gitorious and push to > that. Then we can review the code, pull it down and merge it into the > mainline and push it back up. I'm currently struggling to make git/gitorious use the proper set of ssh keys. I'm going to give up in about twenty seconds and email a diff. > Or, you always could just create a patch and email it to me (and the > list). Then I could review and apply the patch and push from there. > > Speaking of emailing to the list, I noticed you haven't been replying > to the list - only me. I've been trying to add the list back in on my > replies, but may have missed a few. We prefer to keep these > discussions on the list for a few reasons: they are archived for later > reference, and others have an opportunity to contribute etc. Could you > try to remember to hit "reply to all" rather than "reply" in your > email client? I realize we all forget sometimes and I don't mean to be > whiny, but a helpful reminder is good sometimes. I thought it was you who'd first emailed me off-list :) Of course I'm happy to keep this on-list. > Btw, I have a full testing environment, so I can take care of that. > For those that care, I recently documented how I set it up here: > > http://achinghead.com/archive/83/installing-multiple-versions-python/ Excellent, I'll give these instructions a shot, and am happy that you can take care of it in the meantime... E > > -- > ---- > \X/ /-\ `/ |_ /-\ |\| > Waylan Limberg |
|
From: Waylan L. <wa...@gm...> - 2009-01-27 16:38:23
|
On Tue, Jan 27, 2009 at 10:50 AM, Eric Abrahamsen <gi...@gm...> wrote: > > On Jan 27, 2009, at 11:23 PM, Waylan Limberg wrote: >> >> Speaking of emailing to the list, I noticed you haven't been replying >> to the list - only me. I've been trying to add the list back in on my >> replies, but may have missed a few. We prefer to keep these >> discussions on the list for a few reasons: they are archived for later >> reference, and others have an opportunity to contribute etc. Could you >> try to remember to hit "reply to all" rather than "reply" in your >> email client? I realize we all forget sometimes and I don't mean to be >> whiny, but a helpful reminder is good sometimes. > > I thought it was you who'd first emailed me off-list :) Of course I'm > happy to keep this on-list. > Ah, well, I suppose I could see how you got that. In my client (gmail) the list is put in the cc field, so it may have appeared to you that I only sent the message to you. It has always been a small annoyance of mine (that the list ends up in cc), but everyone gets the message, so I haven't worried to much. There's been a many years running debate across the net about which behavior is better, but I don't want to get into that here... Anyway, go ahead and send me the patch. Oh, and don't feel bad. I couldn't get things worked out trying to push to gitorious at first either. What I found is you should first create the clone on gitorious. Then clone locally from your own remote clone -- but use the push url -- That way, later when you want to push, things will already be in place. Then apply your patches to that local clone and push away. There is also the possibility that if you are on debian/ubuntu or any derivatives, your running into a ssh security issue. Recently a bug/hole was discovered and a patch made. If your keys were generated with the old, unpatched ssh, then they will be rejected by any system which has been updated, including gitorious. If so, update shh and regenerate your keys. -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Eric A. <gi...@gm...> - 2009-01-27 16:35:07
|
On Jan 27, 2009, at 11:23 PM, Waylan Limberg wrote: > On Tue, Jan 27, 2009 at 9:58 AM, Eric Abrahamsen <gi...@gm...> > wrote: >> >> Hey there, I've finally got this working. I tried some clever stuff >> with >> subclassing ElementTree, but it was impossible to make work given the >> variety of ElementTrees we might be working with, so I went with the >> brute-force method: copying large chunks of code out of etree1.3. >> I've now >> got something that works as expected with Python 2.5.1 and >> cElementTree, and >> also made some supporting tests. I have never used git before, and >> I'm >> currently failing to add a branch to the mainline repository -- the >> tutorials I'm reading are not doing the trick. Can you tell me >> simply how to >> put this stuff online? I'm working on master, locally, and all my >> changes >> are committed, but I don't know what to do next... >> >> One thing I don't have here is the ability to test this with the >> full range >> of python/ElementTree version variations. If one of you have a full >> test >> environment, that would be great, otherwise I can install a few more >> versions of python on my development machine (something I'll need >> to do >> sooner or later, anyway). Hope all this works out! Let me know what >> to do >> next. >> > > Well, you probably don't have commit access to the mainline repo. What > you should do is create your own cloned repo on gitorious and push to > that. Then we can review the code, pull it down and merge it into the > mainline and push it back up. > > Or, you always could just create a patch and email it to me (and the > list). Then I could review and apply the patch and push from there. > > Speaking of emailing to the list, I noticed you haven't been replying > to the list - only me. I've been trying to add the list back in on my > replies, but may have missed a few. We prefer to keep these > discussions on the list for a few reasons: they are archived for later > reference, and others have an opportunity to contribute etc. Could you > try to remember to hit "reply to all" rather than "reply" in your > email client? I realize we all forget sometimes and I don't mean to be > whiny, but a helpful reminder is good sometimes. > > Btw, I have a full testing environment, so I can take care of that. > For those that care, I recently documented how I set it up here: > > http://achinghead.com/archive/83/installing-multiple-versions-python/ Well getting patches out has been almost as frustrating as creating an online branch, but these four files ought to do it... Eric |
|
From: Waylan L. <wa...@gm...> - 2009-01-27 18:05:04
|
On Tue, Jan 27, 2009 at 11:34 AM, Eric Abrahamsen <gi...@gm...> wrote: > > > Well getting patches out has been almost as frustrating as creating an > online branch, but these four files ought to do it... > > Eric > Just did a quick read through your patches. Looks good. I'll apply them when I get a chance with proper credit etc. One thing I didn't see is the option added to the commandline. But I can do that if you don't get to it first. Now a question to the list: Does anyone have a preference as to what we call the option? Eric added the keyword "method". So ``markdown(text, method="html")`` for example. It doesn't really matter to me, but it occurs to me that the term "method" isn't exactly self documenting. However, it does seem better than anything else I can think of. Oh, and should the options be "html" & "xml" or "html" & "xhtml"? -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Eric A. <gi...@gm...> - 2009-01-27 18:32:50
|
On Jan 28, 2009, at 2:02 AM, Waylan Limberg wrote: > On Tue, Jan 27, 2009 at 11:34 AM, Eric Abrahamsen <gi...@gm...> > wrote: >> >> >> Well getting patches out has been almost as frustrating as creating >> an >> online branch, but these four files ought to do it... >> >> Eric >> > > Just did a quick read through your patches. Looks good. I'll apply > them when I get a chance with proper credit etc. > > One thing I didn't see is the option added to the commandline. But I > can do that if you don't get to it first. I'll try to get to this soon, but I'm hitting the road for a day or two and might not get to it right away... > Now a question to the list: Does anyone have a preference as to what > we call the option? > > Eric added the keyword "method". So ``markdown(text, method="html")`` > for example. It doesn't really matter to me, but it occurs to me that > the term "method" isn't exactly self documenting. However, it does > seem better than anything else I can think of. I used "method" simply because that's what was in the ElementTree alpha. I suppose "format" would be just as accurate, if not more so. > Oh, and should the options be "html" & "xml" or "html" & "xhtml"? For the record, I'm in favor of html vs xhtml, rather than xml vs html, though I don't think it matters all that much. I'm quite willing to do the tweaking when the time comes, if necessary. You mentioned licenses in an earlier email -- most of the additions here are lifted straight out of Fredrik Lundh's most recent 1.3 alpha, do you think we should check with him? I spent more time trying to make git work than I did patching markdown! But it seems to be the wave of the future, so I guess I'll buckle down and study. Eric > > -- > ---- > \X/ /-\ `/ |_ /-\ |\| > Waylan Limberg |
|
From: Yuri T. <qar...@gm...> - 2009-01-27 20:09:09
|
> I used "method" simply because that's what was in the ElementTree > alpha. I suppose "format" would be just as accurate, if not more so. What about "html_version" to make it quite explicit? >> Oh, and should the options be "html" & "xml" or "html" & "xhtml"? I would make it more explicit. Perhaps, "html_4" and "xhtml_1_1". This will give us room for offering "html_5" and "xml_2_0" options later and will also make it more clear what exactly we are supporting. Note, for example, that our default output is not compatible with XHTML 2.0. > You mentioned licenses in an earlier email -- most of the additions > here are lifted straight out of Fredrik Lundh's most recent 1.3 alpha, > do you think we should check with him? Depends on what the license for ElementTree is. Depending on what it is, we may or may not be able to take chunks from it and include it in our BSD code. It's best to ask. - yuri -- http://spu.tnik.org/ |
|
From: Waylan L. <wa...@gm...> - 2009-01-27 23:41:17
|
On Tue, Jan 27, 2009 at 3:09 PM, Yuri Takhteyev <qar...@gm...> wrote:
>> I used "method" simply because that's what was in the ElementTree
>> alpha. I suppose "format" would be just as accurate, if not more so.
>
> What about "html_version" to make it quite explicit?
We could, but if "method" is what ElementTree is already using, then
I'd suggest staying with it. No sense repainting the bikeshed. In
fact, if I had realized that, I wouldn't even have asked.
>
>>> Oh, and should the options be "html" & "xml" or "html" & "xhtml"?
>
> I would make it more explicit. Perhaps, "html_4" and "xhtml_1_1".
> This will give us room for offering "html_5" and "xml_2_0" options
> later and will also make it more clear what exactly we are supporting.
> Note, for example, that our default output is not compatible with
> XHTML 2.0.
How about "html4" & "xhtml1"? Do we really need the extra .1?
Actually, after sending my last email, it occurred to me that we could
easily allow for a few alternatives. Something like:
if method in ['html', 'html4', 'html_4']:
...
Of course, only one of those should be documented, but you get the idea.
>
>> You mentioned licenses in an earlier email -- most of the additions
>> here are lifted straight out of Fredrik Lundh's most recent 1.3 alpha,
>> do you think we should check with him?
>
> Depends on what the license for ElementTree is. Depending on what it
> is, we may or may not be able to take chunks from it and include it in
> our BSD code. It's best to ask.
ElementTree is licensed BSD. I was intending to add a copyright to the
top of the file attributing it accordingly. That should be good
enough, but, when I'm ready to merge it, I'll fire an email off to
Fredrik with a copy attached for good measure.
I should be able to get to it within the next few hours. I'll copy the
list with the message.
--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
|
|
From: Yuri T. <qar...@gm...> - 2009-01-28 00:17:09
|
> We could, but if "method" is what ElementTree is already using, then > I'd suggest staying with it. No sense repainting the bikeshed. In > fact, if I had realized that, I wouldn't even have asked. Not sure if I buy this reason. The name that may make sense in the context of ElementTree may not make sense in the context of Markdown. A typical user doesn't even need to know we are using ElementTree. We should pick a name that makes sense to us. > How about "html4" & "xhtml1"? Do we really need the extra .1? > Actually, after sending my last email, it occurred to me that we could > easily allow for a few alternatives. Something like: > > if method in ['html', 'html4', 'html_4']: We can use underscores or not, but I wouldn't support both, because this would invite confusion. I would, however, provide "html" and "xhtml" as shortcuts. So, perhaps ['html', 'html4'] and ['xhtml', 'xhtml1']. If we later decide to support xhtml 2.0 and make it the default, we can have one handler for ['xhtml1'] and another one for ['xhtml', 'xhtml2']. > ElementTree is licensed BSD. I was intending to add a copyright to the > top of the file attributing it accordingly. That should be good > enough, but, when I'm ready to merge it, I'll fire an email off to > Fredrik with a copy attached for good measure. Where did you find this? The license that accompanies the last release (1.2.7) and shows up svn (http://svn.effbot.org/public/elementtree/README) is vaguely BSD-ish, but is not quite BSD, and appears to prohibit redistribution for a fee. Did they change it since? - yuri -- http://spu.tnik.org/ |
|
From: Waylan L. <wa...@gm...> - 2009-01-28 01:29:22
|
On Tue, Jan 27, 2009 at 7:17 PM, Yuri Takhteyev <qar...@gm...> wrote: >> We could, but if "method" is what ElementTree is already using, then >> I'd suggest staying with it. No sense repainting the bikeshed. In >> fact, if I had realized that, I wouldn't even have asked. > > Not sure if I buy this reason. The name that may make sense in the > context of ElementTree may not make sense in the context of Markdown. > A typical user doesn't even need to know we are using ElementTree. We > should pick a name that makes sense to us. True, now that you mention it. But XHTML is not HTML so "html_version" doesn't work from that perspective. How about "output_format"? It's descriptive and doesn't restrict us to html and variants. Hows that for future proof? > >> How about "html4" & "xhtml1"? Do we really need the extra .1? >> Actually, after sending my last email, it occurred to me that we could >> easily allow for a few alternatives. Something like: >> >> if method in ['html', 'html4', 'html_4']: > > We can use underscores or not, but I wouldn't support both, because > this would invite confusion. I would, however, provide "html" and > "xhtml" as shortcuts. So, perhaps ['html', 'html4'] and ['xhtml', > 'xhtml1']. If we later decide to support xhtml 2.0 and make it the > default, we can have one handler for ['xhtml1'] and another one for > ['xhtml', 'xhtml2']. Sounds good to me. I'm inclined to document the choices as "xhtml" and "html4". Or would you prefer "xhtml1" to be the documented choice? > >> ElementTree is licensed BSD. I was intending to add a copyright to the >> top of the file attributing it accordingly. That should be good >> enough, but, when I'm ready to merge it, I'll fire an email off to >> Fredrik with a copy attached for good measure. > > Where did you find this? The license that accompanies the last release > (1.2.7) and shows up svn > (http://svn.effbot.org/public/elementtree/README) is vaguely BSD-ish, > but is not quite BSD, and appears to prohibit redistribution for a > fee. Did they change it since? Hmm, I thought I checked this when discussing it with Eric the other week. I looked at the license right in the source file on the 1.3 preview branch [1] that we're pulling the code from. But your right, that's not BSD. The only potentially concerning part is "without fee". We won't be charging a fee. Although, the BSD license does allow distribution for a fee. So someone could conceivably charge a fee for Python-Markdown - in which case they would not be able to include the html4.py file. [1]: http://svn.effbot.org/public/elementtree-1.3/elementtree/ElementTree.py -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Yuri T. <qar...@gm...> - 2009-01-28 02:19:05
|
> Sounds good to me. I'm inclined to document the choices as "xhtml" and > "html4". Or would you prefer "xhtml1" to be the documented choice? We should document both, separately. xhtml1 -> outputs XHTML 1.x xhtml -> outputs some version of XHTML, whatever we decide is best (currently XHTML 1.1) html4 -> outputs HTML4.x html -> outpus some version of HTML, whatever we decide makes most sense (HTML 4.0 now, but could be HTML 5 tomorrow) "output_format" is fine. > The only potentially concerning part is "without fee". We won't be > charging a fee. Although, the BSD license does allow distribution for > a fee. So someone could conceivably charge a fee for Python-Markdown - > in which case they would not be able to include the html4.py file. It looks like this usage of "without fee" is quite common in older licenses. It may or may not be BSD compatible. If it's not, then we cannot include chunks of ElementTree and distribute the whole thing under the BSD license. This is a serious issue - we might get dropped from Debian for this. ET is probably now distributed under a different license (PSF?), but to keep it simple, I think we should ask if we can distribute this file under BSD. - yuri -- http://spu.tnik.org/ |
|
From: Waylan L. <wa...@gm...> - 2009-01-28 03:52:48
Attachments:
html4.py
html4_all.diff
|
Ok, I've attached my changes to Eric's patch. "html4_all.diff" includes everything. Apply it against a clean latest copy of python markdown from the mainline repo on Gitorious. "html4.diff" contains only my changes to Eric's work. Use this if you have already applied Eric's patches. All tests pass for Python 2.3, 2.4, 2.5 & 2.6. I did not bother running 2to3 yet. One more question: Eric put the "output_format" keyword in the "convert" & "convertFromFile" methods, not the "__init__" method of the Markdown class. Do we want to set the format for the class (in "__init__") or per call to "convert". The current implementation allows easy output of both formats. However, I wonder if the more common usage is to always require a single format for multiple documents. If so, then it should be set on "__init__" instead. Any input? If/when we receive blessing from Fredrik, I'll commit this pending any suggested changes. -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Waylan L. <wa...@gm...> - 2009-01-28 14:43:49
|
On Tue, Jan 27, 2009 at 10:52 PM, Waylan Limberg <wa...@gm...> wrote: > > If/when we receive blessing from Fredrik, I'll commit this pending any > suggested changes. > Well, Fredrik has given his blessing so, pending any objections to the contrary, I'll push this when I get home today (or during lunch if I have time). For archival purposes, here's Fredrik's response and my request: On Wed, Jan 28, 2009 at 9:31 AM, Fredrik Lundh <fr...@py...> wrote: > Looks good to me! > > Cheers /F > > On Wed, Jan 28, 2009 at 3:03 AM, Waylan Limberg <wa...@gm...> wrote: >> Fredrik, >> >> In our work toward 2.0 of the Python-Markdown project [1] , we have >> switched to using ElementTree (ET). However, as you know, the >> currently distributed versions of ET do not have the option to >> serialize to html. We have noted that your preview of ET 1.3 does >> include such a serializer. Therefore, as per a recent list discussion >> [2] we would like to ask your permission to include the relevant parts >> of your code in our distribution of Python-Markdown. The code would >> remain in it's own separate file and contain your license and >> copyright. A copy is attached for your review. >> >> By my understanding of your license (which could be wrong), this >> should not be a problem and we don't really need to ask, but we would >> prefer your blessing just the same. If you have any questions or >> concerns, please ask. >> >> [1]: http://www.freewisdom.org/projects/python-markdown >> [2]: http://sourceforge.net/mailarchive/forum.php?thread_name=d8b37e750901080454n337cea5er6c0864c5f36eb817%40mail.gmail.com&forum_name=python-markdown-discuss >> >> -- >> ---- >> \X/ /-\ `/ |_ /-\ |\| >> Waylan Limberg >> > -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
×
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