Menu
▾
▴
docutils-develop
|
From: Bill B. <bb...@co...> - 2002-12-24 03:18:42
|
I have successfully modified aahz's OOwriter to produce HTML compliant with O'Reilly's article spec. The end result is a writer that-- while not yet feature complete-- produces a minimal, non-CSS, HTML representation of REST input. In my opinion, it also provides a relatively straightforward example of how to create a writer. If anyone is interested, ping me and I'll forward along a copy of what I have now. Impatience, Laziness and Hubris are the motivating factors-- i.e. it'll likely not spew a correct document for your source because of unknown blocks-- but, given that its focus is on minimalism, it should be easy to fix. (I'd be happy to maintain a sandbox directory, if warranted) Questions: (1) what about support for <code></code> blocks. O'Reilly likes 'em in about as much as they like <pre>. I haven't thought through why I would like one over the other, but it would be nice [in my imagination] to generate both. (2) within <pre></pre> blocks, things like <i></i> and <b></b> work fine. How hard would it be to modify the existing literal block to allow for additional markup via said formatting tags (or am I barking up the wrong tree, here)? In my case, I want to be show a sample session with the Python interpreter and I want to format the output of the interpreter (or the input, can't decide which yet) with slightly different-- italics, bold, etc... I haven't though this stuff through outside of generating HTML for O'Reilly. That is, generating output for other targets may change the requirements/thinking???? (Cool stuff -- the raw article is totally easy to read/edit and the HTML markup is perfect!) b.bum |
|
From: Richard J. <rj...@ek...> - 2002-12-24 04:19:22
|
On Tue, 24 Dec 2002 11:53 am, Bill Bumgarner wrote:
> I have successfully modified aahz's OOwriter to produce HTML compliant
> with O'Reilly's article spec. The end result is a writer that-- while
> not yet feature complete-- produces a minimal, non-CSS, HTML
> representation of REST input. In my opinion, it also provides a
> relatively straightforward example of how to create a writer.
> [snip]
> (I'd be happy to maintain a sandbox directory, if warranted)
Please check the code into the sandbox, even if you're not sure you'll have
time to maintain it. At least it's out in the open then!
Richard
|
|
From: David G. <go...@py...> - 2002-12-24 05:20:27
|
Bill Bumgarner wrote: > I have successfully modified aahz's OOwriter to produce HTML compliant > with O'Reilly's article spec. The end result is a writer that-- while > not yet feature complete-- produces a minimal, non-CSS, HTML > representation of REST input. In my opinion, it also provides a > relatively straightforward example of how to create a writer. > > If anyone is interested, ping me and I'll forward along a copy of what > I have now. Yes please. Let me know your SF user name and I'll add you as a developer too. > (1) what about support for <code></code> blocks. O'Reilly likes 'em in > about as much as they like <pre>. Are you sure about that? <code> is an inline HTML element (like <em>), and <pre> is a block/body-level element (like <p>). How does O'Reilly use them? The html4css1 writer produces <pre> for literal blocks and <tt> for ``inline literals``. I chose <tt> because it's neutral and generic, whereas <code> is more specific. It would be easy to use <code> instead of <tt> if required. > (2) within <pre></pre> blocks, things like <i></i> and <b></b> work > fine. How hard would it be to modify the existing literal block to > allow for additional markup via said formatting tags (or am I barking > up the wrong tree, here)? Check out the "parsed-literal" directive; it does what you're describing. For many examples, see the "Content Model" subsubsections of <http://docutils.sf.net/spec/doctree.html>. > I haven't though this stuff through outside of generating HTML for > O'Reilly. That is, generating output for other targets may change the > requirements/thinking???? A writer producing truly generic HTML, that doesn't rely on CSS, would be a useful addition to the project as an alternate HTML writer. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
|
From: Bill B. <bb...@co...> - 2002-12-24 05:58:02
|
On Tuesday, Dec 24, 2002, at 00:21 US/Eastern, David Goodger wrote: > Are you sure about that? <code> is an inline HTML element (like > <em>), and > <pre> is a block/body-level element (like <p>). How does O'Reilly use > them? > The html4css1 writer produces <pre> for literal blocks and <tt> for > ``inline > literals``. I chose <tt> because it's neutral and generic, whereas > <code> > is more specific. It would be easy to use <code> instead of <tt> if > required. That'd make sense-- the spec really doesn't specify usage by example. Since I haven't actually immersed myself in tag definitions in a while, I decided to do a bit of research: http://www.abiglime.com/webmaster/reference/html/tags/code.htm http://www.abiglime.com/webmaster/reference/html/tags/pre.htm http://werbach.com/barebones/barebones.html http://developer.netscape.com/docs/manuals/htmlguid/alphlist.htm So-- as David kindly indicated-- <code></code> is used inline whereas <pre></pre> is used to mark the preformatted nature of large chunks of text. Makes sense and also makes sense in the context of an article-- use /code/ to delineate an inline example and /pre/ to show off a big chunk of text. (Making up abbreviations on the fly here-- /code/ seems like a nice way to abbreviate <code></code>). I understand that :: basically leads to a literal block, but I don't see anything that causes a parsed-literal to be used instead? Confused, but less so.... b.bum |
|
From: Benja F. <b.f...@gm...> - 2002-12-24 13:43:25
|
Hiya, Bill Bumgarner wrote: > I understand that :: basically leads to a literal block, but I don't > see anything that causes a parsed-literal to be used instead? IIRC parsed-literal is a directive, so, .. parsed-literal:: <something> (where the 'something' is indented, in case my stupid mailer messes that up again :-( ) - Benja |
|
From: Bill B. <bb...@co...> - 2002-12-24 16:05:30
|
On Tuesday, Dec 24, 2002, at 08:42 US/Eastern, Benja Fallenstein wrote: > Hiya, > > Bill Bumgarner wrote: > >> I understand that :: basically leads to a literal block, but I don't >> see anything that causes a parsed-literal to be used instead? > IIRC parsed-literal is a directive, so, > > .. parsed-literal:: > <something> > > (where the 'something' is indented, in case my stupid mailer messes > that up again :-( ) Right. Got it. That works great. But it looks ugly-- it is the first intrusive formatting command I have had to include in the documents. Feature request; maybe if a paragraph ends in :;, the following block is a parsed literal as opposed to a literal block? In general, I'm finding that basic docutils usage is straightforward and easy, but there is a HUGE learning curve between basic usage and advanced/competent/complete usage. I.e. it took me quite a bit of experimentation to figure out how to control section levels. This is not a complaint or criticism-- docutils is at 0.2 and is already of a quality to be both useful and approachable (the ROI is good)-- just a comment. (Heck, PyObjC is in its 7th year of development, is at version 0.8, and *still* doesn't have real docs... :-) The generic/simple HTML parser is now actually useful -- i.e. I'm actually using it to write O'Reilly articles in the format they require and it is considerably faster than using Word, less tedious than writing raw HTML, and a heck of a lot more presentable than doing straight unformatted text. b.bum |
|
From: Benja F. <b.f...@gm...> - 2002-12-24 20:33:09
|
Hi Bill-- Bill Bumgarner wrote: > On Tuesday, Dec 24, 2002, at 08:42 US/Eastern, Benja Fallenstein wrote: > >> Hiya, >> >> Bill Bumgarner wrote: >> >>> I understand that :: basically leads to a literal block, but I don't >>> see anything that causes a parsed-literal to be used instead? >> >> IIRC parsed-literal is a directive, so, >> >> .. parsed-literal:: >> <something> >> >> (where the 'something' is indented, in case my stupid mailer messes >> that up again :-( ) > > > Right. Got it. That works great. > > But it looks ugly-- it is the first intrusive formatting command I > have had to include in the documents. Feature request; maybe if a > paragraph ends in :;, the following block is a parsed literal as > opposed to a literal block? IMHO that wouldn't be worth it-- I don't see this as something used by many users, and it is hackish anyway, because it messes up the alignment of lines-- if I write a UML diagram as ASCII art, I'd have to write: +---------+ | *MyClass* | +---------+ to put the "MyClass" in italics (at least, as far as I understand parsed-literal I have to) for showing that it is an abstract class. Also, I may have to escape asterisks etc. in the code. So, I don't think it is generally useful enough to warrant its own syntax... Just my two cents, of course. - Benja |
|
From: Bill B. <bb...@co...> - 2002-12-24 20:55:10
|
On Tuesday, Dec 24, 2002, at 15:32 US/Eastern, Benja Fallenstein wrote:
> IMHO that wouldn't be worth it-- I don't see this as something used by
> many users, and it is hackish anyway, because it messes up the
> alignment of lines-- if I write a UML diagram as ASCII art, I'd have
> to write:
>
> +---------+
> | *MyClass* |
> +---------+
>
> to put the "MyClass" in italics (at least, as far as I understand
> parsed-literal I have to) for showing that it is an abstract class.
> Also, I may have to escape asterisks etc. in the code. So, I don't
> think it is generally useful enough to warrant its own syntax...
I'm not sure I understand that line of reasoning. Your example-- bold
text in ASCII art-- isn't currently possible if I understand things
correctly (big if, still)?
A specific example: In the article I'm writing, I have examples of
working with an interactive interpreter. I want the output of the
interpreter to be italicized, but-- outside of that-- I want the rest
of it to be treated as a /pre/ block:
-- excerpt --
For example:
.. parsed-literal::
% *python*
Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> *from foo import bar*
>>> *print "foobar"*
foobar
-- end excerpt --
I'd rather simply have the 'For example:' be 'For example:;' (as
opposed to the normal 'For example::').
The request for ':;' was explicitly because it will not require any
changes [that I can think of] to existing REST source. Specifically,
it will not require escaping * characters unless you explicitly request
a parsed-literal block.
It is merely a slight chunk of easily ignored syntactic sugar to give a
hint to the docutils engine-- like the use of _, ``, ::, etc...
b.bum
|
|
From: David G. <go...@py...> - 2002-12-24 21:43:14
|
[Benja Fallenstein] >> IIRC parsed-literal is a directive, so, >> >> .. parsed-literal:: >> <something> [Bill Bumgarner] > Right. Got it. That works great. > > But it looks ugly-- it is the first intrusive formatting command I have > had to include in the documents. Feature request; maybe if a > paragraph ends in :;, the following block is a parsed literal as > opposed to a literal block? Adding ";;" as syntax is already a "to do?" item (search <http://docutils.sf.net/spec/notes.html> for 'Syntax for the "line-block" directive?'). ":;" is equivalent; I can see advantages and disadvantages. Such syntax would be a minor enhancement (or wart, depending on tolerance levels). If you want it, a patch is the best way to get it. Building consensus is also required. You've got to push for it. > In general, I'm finding that basic docutils usage is straightforward > and easy, but there is a HUGE learning curve between basic usage and > advanced/competent/complete usage. I.e. it took me quite a bit of > experimentation to figure out how to control section levels. Why is that? Did you read the docs? Which one(s) (primer, quickref, or full ref)? That's a very basic idea, and should be easily grasped. If it isn't (and if you *did* read at least one of the aforementioned docs), it could be a doc bug. >> IMHO that wouldn't be worth it-- I don't see this as something used by >> many users, and it is hackish anyway, because it messes up the >> alignment of lines-- if I write a UML diagram as ASCII art, I'd have >> to write: >> >> +---------+ >> | *MyClass* | >> +---------+ >> >> to put the "MyClass" in italics (at least, as far as I understand >> parsed-literal I have to) for showing that it is an abstract class. >> Also, I may have to escape asterisks etc. in the code. So, I don't >> think it is generally useful enough to warrant its own syntax... > > I'm not sure I understand that line of reasoning. Your example-- bold > text in ASCII art-- isn't currently possible if I understand things > correctly (big if, still)? Sure it is possible. That's the whole point of the parsed-literal directive:: .. parsed-literal:: +---------+ | *MyClass* | +---------+ One way to get around the fact that markup characters disappear would be to use backslash-escapes in the other lines:: .. parsed-literal:: +-\-------\-+ | *MyClass* | +-\-------\-+ Looks awful though. > A specific example: In the article I'm writing, I have examples of > working with an interactive interpreter. I want the output of the > interpreter to be italicized, but-- outside of that-- I want the rest > of it to be treated as a /pre/ block: I guess you've got that backwards. In your example, the user input is marked up as emphasized, but everything else (interpreter output, prompts, etc.) is not. > The request for ':;' was explicitly because it will not require any > changes [that I can think of] to existing REST source. Specifically, > it will not require escaping * characters unless you explicitly request > a parsed-literal block. I'm not following you. Please explain. > It is merely a slight chunk of easily ignored syntactic sugar to give a > hint to the docutils engine-- like the use of _, ``, ::, etc... It's a syntax addition, no more or less than any other. The question is this: is the added functionality worth the cost of added syntax complexity? -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
|
From: Kirill S. <ki...@mn...> - 2012-09-20 11:31:32
|
Hello, On Tue, Dec 24, 2002 at 04:44:20PM -0500, David Goodger wrote: > [Benja Fallenstein] > >> IIRC parsed-literal is a directive, so, > >> > >> .. parsed-literal:: > >> <something> > > [Bill Bumgarner] > > Right. Got it. That works great. > > > > But it looks ugly-- it is the first intrusive formatting command I have > > had to include in the documents. Feature request; maybe if a > > paragraph ends in :;, the following block is a parsed literal as > > opposed to a literal block? > > Adding ";;" as syntax is already a "to do?" item (search > <http://docutils.sf.net/spec/notes.html> for 'Syntax for the "line-block" > directive?'). ":;" is equivalent; I can see advantages and disadvantages. > > Such syntax would be a minor enhancement (or wart, depending on tolerance > levels). If you want it, a patch is the best way to get it. Building > consensus is also required. You've got to push for it. Just a FYI: I needed it and implemented a patch for it using ::~ suffix. The patch is here: https://sourceforge.net/tracker/?func=detail&aid=3570019&group_id=38414&atid=422032 Attaching it to mail, just in case. Thanks, Kirill ---- 8< ---- From: Kirill Smelkov <ki...@mn...> Date: Thu, 20 Sep 2012 15:06:44 +0400 Subject: [PATCH] rst: Add support for inline parsed-literals via ::~ postfix Just like with :: let's have ::~ to start a parsed-literal block, e.g. like this A paragraph::~ Alpha *beta* gamma Q which is equivalent to A paragraph: .. parsed-literal:: Alpha *beta* gamma Q P.S. The patch was not thoroughly written, because based on earlier experience, I suspect the probability of its inclusion is low. Still imho it's good to have at least as a demo. --- docutils/docutils/parsers/rst/states.py | 32 ++++++++++++-------- .../test_parsers/test_rst/test_literal_blocks.py | 35 ++++++++++++++++++++++ 2 files changed, 55 insertions(+), 12 deletions(-) diff --git a/docutils/docutils/parsers/rst/states.py b/docutils/docutils/parsers/rst/states.py index 0905ab7..9f1a742 100644 --- a/docutils/docutils/parsers/rst/states.py +++ b/docutils/docutils/parsers/rst/states.py @@ -408,14 +408,16 @@ class RSTState(StateWS): Return a list (paragraph & messages) & a boolean: literal_block next? """ data = '\n'.join(lines).rstrip() - if re.search(r'(?<!\\)(\\\\)*::$', data): - if len(data) == 2: - return [], 1 - elif data[-3] in ' \n': - text = data[:-3].rstrip() + m = re.search(r'(?<!\\)(\\\\)*(::(~)?)$', data) + if m: + literalnext = (m.group(3) and 'parsed' or 1) + lenmatch = len(m.group(2)) + if data in ('::', '::~'): + return [], literalnext + elif data[-(lenmatch+1)] in ' \n': + text = data[:-(lenmatch+1)].rstrip() else: - text = data[:-1] - literalnext = 1 + text = data[:-lenmatch] + ':' else: text = data literalnext = 0 @@ -2641,7 +2643,7 @@ class Text(RSTState): context, self.state_machine.abs_line_number() - 1) self.parent += paragraph if literalnext: - self.parent += self.literal_block() + self.parent += self.literal_block(literalnext) return [], 'Body', [] def eof(self, context): @@ -2725,10 +2727,10 @@ class Text(RSTState): self.state_machine.next_line() except EOFError: pass - self.parent += self.literal_block() + self.parent += self.literal_block(literalnext) return [], next_state, [] - def literal_block(self): + def literal_block(self, kind): """Return a list of nodes.""" indented, indent, offset, blank_finish = \ self.state_machine.get_indented() @@ -2737,9 +2739,15 @@ class Text(RSTState): if not indented: return self.quoted_literal_block() data = '\n'.join(indented) - literal_block = nodes.literal_block(data, data) + if kind=='parsed': + text_nodes, messages = self.inline_text(data, offset+1) + literal_block = nodes.literal_block(data, '', *text_nodes) + else: + messages = [] + literal_block = nodes.literal_block(data, data) + literal_block.line = offset + 1 - nodelist = [literal_block] + nodelist = [literal_block] + messages if not blank_finish: nodelist.append(self.unindent_warning('Literal block')) return nodelist diff --git a/docutils/test/test_parsers/test_rst/test_literal_blocks.py b/docutils/test/test_parsers/test_rst/test_literal_blocks.py index d1738dc..4eae886 100755 --- a/docutils/test/test_parsers/test_rst/test_literal_blocks.py +++ b/docutils/test/test_parsers/test_rst/test_literal_blocks.py @@ -364,6 +364,41 @@ $ Inconsistent line. ] +totest['inline_parsed_literal_blocks'] = [ +["""\ +A paragraph:: + + Alpha *beta* gamma + Q +""", +"""\ +<document source="test data"> + <paragraph> + A paragraph: + <literal_block xml:space="preserve"> + Alpha *beta* gamma + Q +"""], +["""\ +A paragraph::~ + + Alpha *beta* gamma + Q +""", +"""\ +<document source="test data"> + <paragraph> + A paragraph: + <literal_block xml:space="preserve"> + Alpha \n\ + <emphasis> + beta + gamma + Q +"""], +] + + if __name__ == '__main__': import unittest unittest.main(defaultTest='suite') -- 1.7.12.1.510.g5dd77d8 |
|
From: Guenter M. <mi...@us...> - 2012-09-23 19:30:07
|
On 2012-09-20, Kirill Smelkov wrote: > Hello, > On Tue, Dec 24, 2002 at 04:44:20PM -0500, David Goodger wrote: >> [Benja Fallenstein] >> >> IIRC parsed-literal is a directive, so, >> >> >> >> .. parsed-literal:: >> >> <something> >> [Bill Bumgarner] >> > Right. Got it. That works great. >> > >> > But it looks ugly-- it is the first intrusive formatting command I have >> > had to include in the documents. Feature request; maybe if a >> > paragraph ends in :;, the following block is a parsed literal as >> > opposed to a literal block? >> Adding ";;" as syntax is already a "to do?" item (search >> <http://docutils.sf.net/spec/notes.html> for 'Syntax for the "line-block" >> directive?'). ":;" is equivalent; I can see advantages and disadvantages. >> Such syntax would be a minor enhancement (or wart, depending on tolerance >> levels). If you want it, a patch is the best way to get it. Building >> consensus is also required. You've got to push for it. > Just a FYI: I needed it and implemented a patch for it using ::~ suffix. > The patch is here: > https://sourceforge.net/tracker/?func=detail&aid=3570019&group_id=38414&atid=422032 My idea is to make the meaning of the "literal block syntax" configurable: Analogue to customising the default role of "interpreted text" with the "default-role" directive, the concise ``::`` literal-block markup could be used for e.g. * a "code-block" directive for syntax highight * the "line-block" directive for poems or addresses * the "parsed-literal" directive Example:: ordinary literal block:: some text typeset in monospace .. default-literal-block:: code-block python this is colourful Python code:: def hello(): print "hello world" In the same line, a "default-block-quote" setting or directive could be considered to configure the role of a block quote. Günter |
|
From: Kirill S. <ki...@mn...> - 2012-09-26 08:15:30
|
Günter, On Sun, Sep 23, 2012 at 07:28:28PM +0000, Guenter Milde wrote: > On 2012-09-20, Kirill Smelkov wrote: > > Hello, > > > On Tue, Dec 24, 2002 at 04:44:20PM -0500, David Goodger wrote: > >> [Benja Fallenstein] > >> >> IIRC parsed-literal is a directive, so, > >> >> > >> >> .. parsed-literal:: > >> >> <something> > > >> [Bill Bumgarner] > >> > Right. Got it. That works great. > >> > > >> > But it looks ugly-- it is the first intrusive formatting command I have > >> > had to include in the documents. Feature request; maybe if a > >> > paragraph ends in :;, the following block is a parsed literal as > >> > opposed to a literal block? > > >> Adding ";;" as syntax is already a "to do?" item (search > >> <http://docutils.sf.net/spec/notes.html> for 'Syntax for the "line-block" > >> directive?'). ":;" is equivalent; I can see advantages and disadvantages. > > >> Such syntax would be a minor enhancement (or wart, depending on tolerance > >> levels). If you want it, a patch is the best way to get it. Building > >> consensus is also required. You've got to push for it. > > > Just a FYI: I needed it and implemented a patch for it using ::~ suffix. > > The patch is here: > > > https://sourceforge.net/tracker/?func=detail&aid=3570019&group_id=38414&atid=422032 > > My idea is to make the meaning of the "literal block syntax" configurable: > > Analogue to customising the default role of "interpreted text" with the > "default-role" directive, the concise ``::`` literal-block markup could be > used for e.g. > > * a "code-block" directive for syntax highight > > * the "line-block" directive for poems or addresses > > * the "parsed-literal" directive > > Example:: > > ordinary literal block:: > > some text typeset in monospace > > .. default-literal-block:: code-block python > > this is colourful Python code:: > > def hello(): > print "hello world" > > > In the same line, a "default-block-quote" setting or directive could be > considered to configure the role of a block quote. I think it is maybe useful to be able to set the default style, and considering analogue with roles something like the following could be used: ordinary literal block:: some text text text ... a code block::(code) some code etc... but as with roles we have :emphasis: and :strong: etc, we also have shortcuts like "*text*" and "**text**" or the text could quickly become more verbose and less .txt like. So my imho is that having a shortcut (maybe tunable) for parsed literal block still would be a good thing. Thanks for replying, Kirill |
|
From: Aahz <aa...@py...> - 2002-12-24 21:10:28
|
On Mon, Dec 23, 2002, Bill Bumgarner wrote: > > I have successfully modified aahz's OOwriter to produce HTML compliant > with O'Reilly's article spec. The end result is a writer that-- while > not yet feature complete-- produces a minimal, non-CSS, HTML > representation of REST input. In my opinion, it also provides a > relatively straightforward example of how to create a writer. Cool! I've been bad-mouthing my own code, but if someone else was able to use it, I'm glad I uploaded it after all. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ "I disrespectfully agree." --SJM |
|
From: Bill B. <bb...@co...> - 2002-12-24 21:30:46
|
On Tuesday, Dec 24, 2002, at 16:10 US/Eastern, Aahz wrote: > On Mon, Dec 23, 2002, Bill Bumgarner wrote: >> I have successfully modified aahz's OOwriter to produce HTML compliant >> with O'Reilly's article spec. The end result is a writer that-- while >> not yet feature complete-- produces a minimal, non-CSS, HTML >> representation of REST input. In my opinion, it also provides a >> relatively straightforward example of how to create a writer. > Cool! I've been bad-mouthing my own code, but if someone else was able > to use it, I'm glad I uploaded it after all. It is far from complete, but the generic HTML writer is useful now [at least to me]. It can do footnotes, handles literal and parsed-literal blocks, table of contents, links, basic formatting stuff, text (of course), sections, a handful of fields, and is becoming easier and easier to extend. At this point, it is a combination of Aahz's code and the original html4css.py writer. Somewhere along the way, I blew up settings and eliminated them-- I need to get the article done someday soon!-- but they should be easy to restore. Writing generic HTML has driven home exactly how painful HTML truly is. Namely, there are times where <p>, <br /> and nothing at all can imply a paragraph and using the wrong one can lead to extra ugly whitespace. That was fun to work around. I would really like to refactor the footnote code as it is currently spewing a whole slew of tables as opposed to a single table. No CSS anywhere, but the output is fairly reasonable. Good enough for my purposes anyway. As soon as I have commit rights into the sandbox, I'll create a bbum directory and commit the module along w/a simple setup.py [my sf account is bbum, btw]. I'm seriously looking forward to getting feedback on the code from those that actually know what they are doing because I'm largely pecking in the dark, at this point. b.bum |
×
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