gmane.text.docutils.devel

Re: [Docutils-checkins] r5739 - in trunk/docutils: HISTORY.txt test/test_functional.py tools/buildhtml.py

2008-12-01T07:24:26

Sorry fixed. On Sun, 30 Nov 2008, David Goodger wrote:

Re: Python 3.0 porting types diff

Aahz — 2008-12-01T04:51:51

Works for me: 2.2 was released 12/2001 and 2.3 was released 7/2003.

Re: Python 3.0 porting types diff

David Goodger — 2008-11-30T17:44:55

We could drop Python 2.2 compatibility for Docutils 0.6+. Any objections? Patches that are sent to mailing lists are sometimes lost. We should use the same rules as python-dev. And SF isn't *that* bad. ;-)

Re: [Docutils-checkins] r5739 - intrunk/docutils: HISTORY.txt test/test_functional.pytools/buildhtml.py

David Goodger — 2008-11-30T17:40:34

This patch doesn't do anything; it doesn't introduce os.walk. Please fix or revert.

Re: Python 3.0 porting types diff

2008-11-30T16:16:15

run the tests now and then against 2.2 to 2.6. i will do it more often if need arises or someone requests no idea. the longer the better i think. it is not mandatory in this project, if you dont wantg to, patches might get lost easier in email. all the best

Re: Python 3.0 porting types diff

Peter Funk — 2008-11-30T12:15:52

Hello all, Georg Brandl asked Sunday, 30.11.2008 at 11:52: ... Disclaimer: I can't speak for the docutils development, because I didn't contribute anything here during the last years. I'm working as a software developer since 1986. With my personal experience I would say that keeping backward compatibility has been proven to be a very worthwhile good which shouldn't be dropped lightheaded. My company has still customers out there running rather old systems where Python 1.5.2 was the default /usr/bin/python included with the OS distribution. ;-) Fortunately we are using doc-utils only inhouse and the oldest server in use with has already Python 2.4.3. As general rules of thumb for packages trying to gain good platform portability I would suggest the following: * Don't rely on any new programming language features, unless they were available eight years ago. * Don't rely on operating system features, unless they were available ten years ago. Of course there is always the option to work aro

Re: Python 3.0 porting types diff

Georg Brandl — 2008-11-30T10:52:58

grubert< at >users.sourceforge.net schrieb: OK, I didn't test that here. Maybe I really should build a Python 2.2 :-) Related question: For how long will the 2.2 compatibility requirement be upheld? I will if you insist, but I thought I'd spare everyone the trouble that is using SourceForge ;-) Georg

Re: Python 3.0 porting

2008-11-30T10:02:55

committed all three (as far as possible) cheers

Re: Python 3.0 porting

2008-11-30T09:53:08

2.2 does not have os.walk, i did put some try/except into fro 2.2. cheers

Re: Python 3.0 porting

2008-11-30T09:00:19

add SliceType to this. the rest is committed. thanks

Re: Python 3.0 porting types diff

2008-11-30T08:51:39

in python2.2 slice is a built-in function i guess that is why it says 'TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types' you could post the patches to sourceforge maybe , then we have a clearer subject line (and we might get bigger numbers on the change counters). but this is up to you cheers

Re: Python 3.0 porting

Georg Brandl — 2008-11-27T20:15:35

Georg Brandl schrieb: Third, even more trivial patch: return a boolean from __nonzero__. Georg Index: docutils/nodes.py =================================================================== --- docutils/nodes.py(Revision 5728) +++ docutils/nodes.py(Arbeitskopie) < at >< at > -58,7 +58,7 < at >< at > Use `len()` to check node length. Use `None` to represent a boolean false value. """ - return 1 + return True def __str__(self): return unicode(self).encode('raw_unicode_escape') < at >< at > -292,7 +292,7 < at >< at > def __new__(cls, data, rawsource=None): """Prevent the rawsource argument from propagating to str.""" return reprunicode.__new__(cls, data) - + def __init__(self, data, rawsource=''): self.rawsource = rawsource ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes

Re: Python 3.0 porting

Georg Brandl — 2008-11-27T20:14:17

Georg Brandl schrieb: Second (shorter) patch: get rid of os.path.walk. Georg Index: test/test_functional.py =================================================================== --- test/test_functional.py(Revision 5728) +++ test/test_functional.py(Arbeitskopie) < at >< at > -39,7 +39,16 < at >< at > os.chdir(DocutilsTestSupport.testroot) self.clear_output_directory() self.added = 0 - os.path.walk(join_path(datadir, 'tests'), self.walker, None) + for root, dirs, files in os.walk(join_path(datadir, 'tests')): + # Process all config files among `names` in `dirname`. A config + # file is a Python file (*.py) which sets several variables. + for name in files: + if name.endswith('.py') and not name.startswith('_'): + config_file_full_path = join_path(root, name) + self.addTestCase(FunctionalTestCase, 'test', None, None, + id=config_file_full_path, +

Re: Python 3.0 porting

Georg Brandl — 2008-11-27T19:55:18

Georg Brandl schrieb: OK, after the encouraging post from Alan I'll try to find a way to let 2to3 do all the work. It may also be possible to write custom fixers for 2to3 that fix things the stock tool can't generally do. I'll send patches for some changes that can be made without breaking any compatibility. The first removes all unnecessary use of the "types" module whose trivial attributes like StringType are gone in 3k. Usage of ClassType remains however and must (ATM) be fixed manually. Georg Index: test/package_unittest.py =================================================================== --- test/package_unittest.py(Revision 5728) +++ test/package_unittest.py(Arbeitskopie) < at >< at > -116,8 +116,7 < at >< at > continue if type(suite) == types.FunctionType: testSuite.addTest(suite()) - elif type(suite) == types.InstanceType \ - and isinstance(suite, unittest.TestSuite): + elif isinstance(suite, unittest.TestSuite):

Re: website updates: SF shell is back

Guenter Milde — 2008-11-27T08:33:14

David Goodger python.org> schrieb: With the remote server, I had to do the cleaning 3 times (locally|SVN, berlios/aux and SF). With local updates, files I remove from SF remain on the local contributors machines and will be restored with the next rsync (if no special care is taken). Günter ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Docutils-develop mailing list Docutils-develop< at >lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/docutils-develop Please use "Reply All" to reply to the list.

Re: website updates: SF shell is back

David Goodger — 2008-11-26T14:51:21

Maybe, I haven't checked. I'm inclined to abandon that approach though. I don't see how that would be any worse on a local build than on a remote server. It's not that big of a problem IMO. Can you explain further?

[ docutils-Bugs-2350865 ] Empty block commentscause wrong syntax coloring in Emacs

SourceForge.net — 2008-11-26T13:34:56

Bugs item #2350865, was opened at 2008-11-26 14:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=2350865&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jérôme M. Berger (voiz) Assigned to: Nobody/Anonymous (nobody) Summary: Empty block comments cause wrong syntax coloring in Emacs Initial Comment: The following example will be colored entirely as if it were a block comment, including the normal text line at the end: ====================8<-------------------- .. First comment paragraph .. .. Second comment paragraph Normal text -------------------->8==================== This is with the ``rst.el`` from version 0.5. -------------------------------------------

Re: website updates: SF shell is back

Guenter Milde — 2008-11-26T08:54:02

David Goodger python.org> schrieb: Would this allow to safely rsync between berlios.de and SF? I have no preference as there are pros and cons for either approach. My problem is that currently files that are (re)moved in the SVN are not (re)moved in the web space. The "local-build and rsync" could complicate things further: after a boring and tedious cleaning of docutils.sf.net, rsync from a local mirror might bring back all the obsolete files. Günter ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Docutils-develop mailing list Docutils-develop< at >lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/docutils-devel

Re: Python 3.0 porting

Alan G Isaac — 2008-11-26T02:05:05

Just a comment on this thread. Some time ago I wanted docutils on Python 3.0. At the time the 2to3 tool was not working for me, so I did it by hand. It took about an hour to get it working well enough for my purposes then. Almost all the changes were trivial. Working from memory, there were the following problems. - change print to function - a small number of places required changing the exception handling to the new syntax - a few places where unicode string handling had to be changed - one change in package name in the standard library Almost all of this should be trivial for the 2to3 tool. There might be a few places for minor changes to help the tool along. Unfortunately there was some subtlety with unicode string handling at one point, but I'd have to dig back to figure out what it was. Bottom line: I suspect it is quite feasible to make some cosmetic changes to the code base and then just work with the 2to3 tool. fwiw, Alan Isaac ---------------------------------------------------------

Re: Python 3.0 porting

Georg Brandl — 2008-11-25T21:13:24

David Goodger schrieb: > > The website says that Python 2.2 is still supported. Since the "single codebase" strategy relies on the 2to3 conversion doing everything needed to make it run on 3k, the more backwards compatible you have to stay, the more impossible this is. It works best for code that only needs to run on 2.6, which is of course not possible for Docutils. There might be a way to do it, using two converters: one to 2.x, one to 3.x code. Ok. Georg ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Python 3.0 porting

David Goodger — 2008-11-25T21:03:49

I am. What do you mean? I don't know if that will work or not -- it might! If we need a branch, I think /branches/ would be best.