rest2web-develop — A discussion list for rest2web development.

[Rest2web-develop] Rest2web Progress

[Michael F. <mi...@pc...>]

Hello Folks,

Finally progress on rest2web (a time for all things).

I've done a new check-in and am *actively* working on fixing things for
the new release.

The latest check-in includes a couple of bugfixes.

The next release will have the gallery and the following features :

    Adding file keyword
    Adding tags keyword
    Bugfix to ``thispage`` (not broken anymore)
    Added section-pages keyword (a way of specifying the order of pages
in sections)
    Added '__prune__'  *file* so you can block processing of directories
    Depends on Pythonutils 0.2.2 or more recent

I'm also refactoring the docs so that it has a proper tutorial and the
main page is a bit less confusing. rest2web has always been simple to
use in it's basic form - but the restindex and templates have so many
*optional* features that it might not seem that way.

I estimate  I should get this done within a week or so, it has finally
risen to the top of the pile :-)

The plugin system will be included - but I'm not sure if I'll fully
document/announce it with the next release. I have an 'encoding' issue
[#]_ that I need to think about before it's solid. The plugin system
will allow all sorts of useful things - like a sitemap generator, tag
cloud system, etc.

I'm also considering turning the templating and markup into plugins -
allowing people to use alternative systems.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python

.. [#] The issue is that *currently (because of the order things are
processed) plugins need to return their output in the same encoding as
the content - which is fine so long as the output of the plugin can
*always* be expressed in the encoding of the content....

[Rest2web-develop] Having a reST

[<mi...@pc...>]

{emo;html} I've had a productive weekend - although I wrote very little code.

I've managed to convert over several of my website index pages to using rest2web__.

Unlike articles - which are mainly text and images, with a few footnotes etc thrown in - index pages aren't obviously suitable for storing in reST__ format. I was still looking for some way of making them easier to maintain.

I've mastered a few more details of {acro;reST;ReStructured Text} now - including creating macros for generating index tables etc [#]_.

If you look at a page like `python modules`__ - it's not obviously come from a reST document [#]_ ... but it has. Basically all the text is now stored as plain text - with docutils doing the HTML generation.

It is now *much* easier for me to convert the remaining portions of my website over to using rest2web. {sm;:grin:}


.. class:: invisible

.. note::

    Sorry to abuse my blog (and your patience) like this. For the sake of google I'd like to mention http://www.garycefai.co.uk, http://www.nebulae.org.uk, and http://www.buildingtrade.org.uk.


.. [#] Other than a few tell tale clues... like the footnotes style.

.. [#] I'm having to use the ``.. raw:: html`` directive to put multiple elements into a ``div`` block with a specific class.

__ /python/rest2web/
__ http://docutils.sourceforge.net
__ /python/modules.shtml

[Rest2web-develop] The Gallery

[Michael F. <mi...@pc...>]

Hello,

For those who might be interested - the results of the rest2web gallery
script can now be viewed at :

http://www.voidspace.org.uk/gallery/index.shtml

By the way - developers using ConfigObj who have not yet switched to the
configobj-develop list should note there is an important ConfigObj
announcement there (Beta 4 release). You can find sign up details for
the mailing list on the sourceforge page :

http://sf.net/projects/configobj

All the best,


Fuzzyman
http://www.voidspace.org.uk/python

[Rest2web-develop] rest2web Progress and Thoughts

[Michael F. <mi...@pc...>]

Hello All,

At last a rest2web related email on the rest2web mailing list :-)


After a lot of work the new ConfigObj and pythonutils are nearly ready.
This means my focus has switched back to rest2web. (rest2web uses the
new version of pythonutils by the way).

I'm working towards a new release. The version currently in SVN already
features the gallery and fixes 'thispage' which was basically broken
from the start. It now works properly. 'page_description' is also
available as a value in the templates.

There are also other minor fixes etc.

The next release will include :

	the gallery
	ordered pages within a section
	a new 'file' keyword in the restindex

I probably won't complete the plugin system before I do a new release.
It basically works - but there is a difficult encoding problem (related
to the order that things are processed) that I can't be bothered to
think about.

The plugin system could potentially be used to bolt on an alternative
templating system by the way - like cheetah. If anyone *wanted* to do
that I'd be happy to work on integrating it better.

rest2web also badly needs a tutorial. It has lots of options in the
restindex and lots of values available in the templates. This makes the
documentation 'dense' and seem complicated. A basic site can be achieved
*very simply* in rest2web though.

Also a brief note about 'dynamic sites'. With some optimisation and
'content caching' combined with 'pickling' of data structures - it would
be possible to use rest2web as a framework to deliver dynamic content.

All the best,


Fuzzyman
http://www.voidspace.org.uk/python

[Rest2web-develop] ConfigObj Bug and New Release

[Michael F. <mi...@pc...>]

Hello All,

This is the last ConfigObj related email that I'll send to this list
(well, unless this starts a thread).

Unfortunately there is a serious bug in ConfigObj Beta 3 and all
previous versions. This causes the 'inline_comments' attribute of a
section to be deleted when you delete any member of the ConfigObj. (oops)

This is already fixed in subversion and a new (Beta 4) release will be
done tomorrow - along with a Pythonutils 0.2.1 release. This version
will also be available from sourceforge.

http://sf.net/projects/configobj

Thanks

Fuzzyman
http://www.voidspace.org.uk/python

[Rest2web-develop] ConfigObj development List

[Michael F. <mi...@pc...>]

Hello All,

I've just created a 'configobj-develop' mailing list at sourceforge.
This will take a few hours to be setup - then access to it will eb
available from the ConfigObj project page.

From then all ConfigObj news/discussion will move to their :

con...@li...

This mailing list will become more rest2web focussed.

Thanks

Fuzzyman
http://www.voidspace.org.uk/python

[Rest2web-develop] Pythonutils and ConfigObj

[Michael F. <mi...@pc...>]

Hello all,

I'm back after a bit of a break.

I've just done a fresh commit - :

* minor updates to rest2web
* Major updates to the pythonutils modules
* Completed pythonutils documentation
* Bugfixes to ConfigObj

On the basis of this I'm doing a pythonutils-0.2.0 release and a
ConfigObj-4.0.0 beta 3 release.

The changes to ConfigObj are :

    Interpolation is switched off before writing out files.

    String values unchanged by validation *aren't* reset. This preserves
    interpolation in string values.
  
    Fixed bug in handling ``StringIO`` instances. (Thanks to report from
    "Gustavo Niemeyer" <gu...@ni...>)
   
    Moved the doctests from the ``__init__`` method to a separate function.
    (For the sake of IDE calltips).

The updates will be online at voidspace shortly.....

All the best,


Fuzzyman
http://www.voidspace.org.uk/python

Re: [Rest2web-develop] ConfigObj 4 Beta 1

[Michael F. <mi...@pc...>]

Nicola Larosa wrote:
[snip..]
> 
> Overall, green light to official beta release from me! :-D
> 

Done... at least updated and uploaded.
A final check on the zip file before I announce would be nice.

http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=configobj-4.0.0b2.zip

Thanks
Fuzzy
http://www.voidspace.org.uk/python

[Rest2web-develop] ConfigObj Beta 2 release

[Michael F. <mi...@pc...>]

Hello All,

I'm finalising the beta 2 release of ConfigObj.

Amendments to the validate.py exception classes have been made. Docs and
API docs updated accordingly.

A setup.py for configobj and validate has been created. I'm using this
to create the source distributions and manually adding docs (etc). I'm
not intending to build a windows executable installer, or to hack the
setup.py to move the docs for the user.

The *distributed* API docs no longer include the private objects. This
means that the ``Section`` object (and methods) don't get documented in
the API docs. This *doesn't* apply to the online version.

All distributed text/html should now have LF line endings rather than
CR/LF.....

The name of the zipfile has changed. It is now
``configobj-4.0.0b2.zip``. This does have the side effect that there is
no canonical download URL for the *latest* version [#]_. I could *also*
create (and maintain) a ``configobj-LATEST.zip`` [#]_, but I can't be
bothered.....

Also - the doctests mean that all the docstrings are invalid ReST.
Epydoc leaves them as plain text, which still looks pretty good.

Changes committed - release and announcement following shortly...

Last minute proof reading/tests/checks still appreciated.

All the best,


Fuzzyman
http://www.voidsapce.org.uk/python


.. [#] Meaning that download links in downloaded documentation, and also
online in validate.html and other places, go out of date.
.. [#] This is the approach that David Mertz uses with his GnosisUtils.
This is also the reason I was just using ``configobj.zip``.

Re: [Rest2web-develop] ConfigObj 4 Beta 1

[Michael F. <mi...@pc...>]

Nicola Larosa wrote:
>>3a. the two doctests in the ConfigObj class docstring should raise
>>    DuplicateError, but instead raise ConfigObjError;
> 
> 
> I added "raise_errors = True" to the tests, and changed the expected output
> to match the new one.
> 

Ahh... :-) Well caught.

> 
> 
>>>>3b. we may want to try minimizing the usage of the isinstance
>>>>    built-in, especially to allow passing dict-like objects that
>>>>    are not subclasses of dict;
> 
> 
>>>What alternative do you suggest ?
>>>
>>>``IsmappingType`` is hopeless (it returns ``True`` for *any* class). I
>>>don't think restricting input to dicts or genuine subclasses is too
>>>restrictive.
> 
> 
>>That's what he asked for.
> 
> 
>>>We could assume that any item with a ``__getitem__`` method *and* a
>>>``keys`` method will behave like a dictionary ? (I'd be happy with this
>>>as a solution - but it will need documenting).
> 
> 
>>Some kind of duck typing, yes, I'll explore current usage.
> 
> 
> I tried using "dict(value)" in a try...except block, but things are
> complicated by the fact that both "dict('')" and "dict(())" succeed,
> returning the empty dict.
> 
> Let's keep it all as it is; if someone wants to pass in a non-dict-derived
> dict-like thing, it's their responsibility to convert it to dict first.
> 

Yeah - dict(value) is hardly a *great* chore. Nice one.

> 
> 
>>>>6. the "BSD-LICENSE.txt" and the generated HTML files have CRLF
>>>>   line endings, while the sources have LF ones. Also, the
>>>>   "configobj.txt" has LF ones, except for the HTML fragment at the
>>>>   end, that has ten CRLF endings.
> 
> 
>>>Ok - I can sort this. Committing will remove the carriage returns from
>>>configobj.txt.
> 
> 
>>Just updated, and it didn't. :-( I'll fix the files and their svn:eol-style
>>property.
> 
> 
> I set the svn:eol-style property on all files in the repository except GIF
> and JPG images, and removed all CR chars from all the other files.
> 

Thanks

> I set all properties to 'LF' instead of 'native'. In this way the files
> will keep their LF endings on Windows too, instead of being converted back
> and forth to CRLF.
> 

Great

> Apart from being The Right Thing (tm), ;-) this will ease your packaging
> job, and won't create problems with editing: just set SPE to use the
> original line endings of each file, without changing them.
> 
> You won't be able to open those files with Notepad anymore, but Wordpad
> reads them, and correctly writes them, just fine. ;-)
> 

No problem - SPE (and most python tools) preserve line endings. I use a
nice text editor which does too.

> 
> Overall, green light to official beta release from me! :-D
> 

Oh good... my low key mention on my blog got put up on Daily Python URL
! I need to edit the doc files to use the new zip file name. (and make
the change to validate.py)

Then I'll sort it... later today.  I'm just installing Namazu on the server.

Fuzzy
http://www.voidspace.org.uk/python

Re: [Rest2web-develop] ConfigObj 4 Beta 1

[Nicola L. <ni...@te...>]

> 3a. the two doctests in the ConfigObj class docstring should raise
>     DuplicateError, but instead raise ConfigObjError;

I added "raise_errors = True" to the tests, and changed the expected output
to match the new one.


>>> 3b. we may want to try minimizing the usage of the isinstance
>>>     built-in, especially to allow passing dict-like objects that
>>>     are not subclasses of dict;

>> What alternative do you suggest ?
>>
>> ``IsmappingType`` is hopeless (it returns ``True`` for *any* class). I
>> don't think restricting input to dicts or genuine subclasses is too
>> restrictive.

> That's what he asked for.

>> We could assume that any item with a ``__getitem__`` method *and* a
>> ``keys`` method will behave like a dictionary ? (I'd be happy with this
>> as a solution - but it will need documenting).

> Some kind of duck typing, yes, I'll explore current usage.

I tried using "dict(value)" in a try...except block, but things are
complicated by the fact that both "dict('')" and "dict(())" succeed,
returning the empty dict.

Let's keep it all as it is; if someone wants to pass in a non-dict-derived
dict-like thing, it's their responsibility to convert it to dict first.


>>> 6. the "BSD-LICENSE.txt" and the generated HTML files have CRLF
>>>    line endings, while the sources have LF ones. Also, the
>>>    "configobj.txt" has LF ones, except for the HTML fragment at the
>>>    end, that has ten CRLF endings.

>> Ok - I can sort this. Committing will remove the carriage returns from
>> configobj.txt.

> Just updated, and it didn't. :-( I'll fix the files and their svn:eol-style
> property.

I set the svn:eol-style property on all files in the repository except GIF
and JPG images, and removed all CR chars from all the other files.

I set all properties to 'LF' instead of 'native'. In this way the files
will keep their LF endings on Windows too, instead of being converted back
and forth to CRLF.

Apart from being The Right Thing (tm), ;-) this will ease your packaging
job, and won't create problems with editing: just set SPE to use the
original line endings of each file, without changing them.

You won't be able to open those files with Notepad anymore, but Wordpad
reads them, and correctly writes them, just fine. ;-)


Overall, green light to official beta release from me! :-D

-- 
Nicola Larosa - ni...@te...

Any fool can talk, but it takes a wise man to listen.
 -- AccUser on Slashdot, July 2005

Re: [Rest2web-develop] ValidateParamError

[Nicola L. <ni...@te...>]

> Note the following issue with ``ValidateParamError`` in validate.py :
> 
>     Because ``ValidateParamError`` is a subclass of ``ValidateError``,
> it will
>     always be trapped by ConfigObj as a failed check. Should we get
> ConfigObj to
>     propagate this error ? (as it is a programmer error and not a failed
> check)
> 
> The easiest way to get round it is to either create a new error class
> that isn't a subclass of ``ValidateError`` - or use a built in Exception.

The first solution is best, and meaningful too. It's a different class of
Errors, after all. We should have more of them. ;-)


> By the way - thanks for your work on the docs.

You're welcome.


-- 
Nicola Larosa - ni...@te...

Any fool can talk, but it takes a wise man to listen.
 -- AccUser on Slashdot, July 2005

Re: [Rest2web-develop] ConfigObj 4 Beta 1

[Nicola L. <ni...@te...>]

>> 1. the zip file, *and* the main directory inside it, should be named
>>    "configobj-4.0.0b1";

> Ok (This is the *highest* priority - the *name* of the zip file ? ;-)

Of course. It' a *human* issue, and takes precedence over the merely
technical ones. ;-)


>> 2. we should have a simple "setup.py" file in there;

> Great if you can do one. I'm about to commit a setup.py  for
> 'pythonutils' though.... (marginally less trivial because it generates
> the '.pth' file when used).

Let's recycle yours, then. :-)


>> 3b. we may want to try minimizing the usage of the isinstance
>>     built-in, especially to allow passing dict-like objects that
>>     are not subclasses of dict;

> What alternative do you suggest ?
> 
> ``IsmappingType`` is hopeless (it returns ``True`` for *any* class). I
> don't think restricting input to dicts or genuine subclasses is too
> restrictive.

That's what he asked for.


> We could assume that any item with a ``__getitem__`` method *and* a
> ``keys`` method will behave like a dictionary ? (I'd be happy with this
> as a solution - but it will need documenting).

Some kind of duck typing, yes, I'll explore current usage.


>> 4. we may want to omit the private API docs, by using the
>>    "--no-private" switch of the epydoc command;

> I think that removes *all* the Section documentation. I don't have a
> problem with distributing the private documentation - it's all nicely
> written.

My concern was about the size of the package.


>> 5. it would be nice to have a tar.gz file on Sourceforge, in addition
>>    to the zip: it's smaller than the zip, and more "native" to Linux;

> I can upload it if you generate it :-)
> Or I can add you to the sourceforge project ? (Let me know your user
> name and I'll add you)

Yes, I wanted to ask you about that. :-) It's "teknico" (lower case "n"),
of course.


>> 6. the "BSD-LICENSE.txt" and the generated HTML files have CRLF
>>    line endings, while the sources have LF ones. Also, the
>>    "configobj.txt" has LF ones, except for the HTML fragment at the
>>    end, that has ten CRLF endings.

> Ok - I can sort this. Committing will remove the carriage returns from
> configobj.txt.

Just updated, and it didn't. :-( I'll fix the files and their svn:eol-style
property.

-- 
Nicola Larosa - ni...@te...

PHP is such a load of crap, right down to the standard library, that it
creates a culture where it's acceptable to write horrible code. [...]
Maybe with PHP 5 they are trying to clean up the neighborhood, but that
doesn't change the fact when you program in PHP you are programming in
a dump. -- Ian Bicking, July 2005

Re: [Rest2web-develop] ConfigObj 4 Beta 1

[Michael F. <mi...@pc...>]

Nicola Larosa wrote:
>>It would be appreciated if you could the zips and standalone files and
>>check they are 'unmangled' and the documentation files look ok from the
>>zip. I'm not at any kind of development station - so doing this myself
>>is a PITA.
> 
> 
> There's a number of issues, mainly minor. I list them in descending
> priority order.
> 
> 1. the zip file, *and* the main directory inside it, should be named
>    "configobj-4.0.0b1";
> 

Ok (This is the *highest* priority - the *name* of the zip file ? ;-)

> 2. we should have a simple "setup.py" file in there;
> 

Great if you can do one. I'm about to commit a setup.py  for
'pythonutils' though.... (marginally less trivial because it generates
the '.pth' file when used).

> 3. a friend of mine pointed out two problems:
> 
>   3a. the two doctests in the ConfigObj class docstring should raise
>       DuplicateError, but instead raise ConfigObjError;
> 

Ok - I'll leave you to sort it :-)

>   3b. we may want to try minimizing the usage of the isinstance
>       built-in, especially to allow passing dict-like objects that
>       are not subclasses of dict;
> 

What alternative do you suggest ?

``IsmappingType`` is hopeless (it returns ``True`` for *any* class). I
don't think restricting input to dicts or genuine subclasses is too
restrictive.

We could assume that any item with a ``__getitem__`` method *and* a
``keys`` method will behave like a dictionary ? (I'd be happy with this
as a solution - but it will need documenting).

> 4. we may want to omit the private API docs, by using the
>    "--no-private" switch of the epydoc command;
> 

I think that removes *all* the Section documentation. I don't have a
problem with distributing the private documentation - it's all nicely
written.

> 5. it would be nice to have a tar.gz file on Sourceforge, in addition
>    to the zip: it's smaller than the zip, and more "native" to Linux;
> 

I can upload it if you generate it :-)
Or I can add you to the sourceforge project ? (Let me know your user
name and I'll add you)

> 6. the "BSD-LICENSE.txt" and the generated HTML files have CRLF
>    line endings, while the sources have LF ones. Also, the
>    "configobj.txt" has LF ones, except for the HTML fragment at the
>    end, that has ten CRLF endings.
> 

Ok - I can sort this. Committing will remove the carriage returns from
configobj.txt.

I can remove them from the generated HTML. I've changed these slightly
anyway. I'm about to commit all my changes.

> I'll check issues 2. , 3a. and 3b . Let me know how to address issue 6. .
> 

Best Regards,


Fuzzy
http://www.voidspace.org.uk/python

Re: [Rest2web-develop] ConfigObj 4 Beta 1

[Nicola L. <ni...@te...>]

> It would be appreciated if you could the zips and standalone files and
> check they are 'unmangled' and the documentation files look ok from the
> zip. I'm not at any kind of development station - so doing this myself
> is a PITA.

There's a number of issues, mainly minor. I list them in descending
priority order.

1. the zip file, *and* the main directory inside it, should be named
   "configobj-4.0.0b1";

2. we should have a simple "setup.py" file in there;

3. a friend of mine pointed out two problems:

  3a. the two doctests in the ConfigObj class docstring should raise
      DuplicateError, but instead raise ConfigObjError;

  3b. we may want to try minimizing the usage of the isinstance
      built-in, especially to allow passing dict-like objects that
      are not subclasses of dict;

4. we may want to omit the private API docs, by using the
   "--no-private" switch of the epydoc command;

5. it would be nice to have a tar.gz file on Sourceforge, in addition
   to the zip: it's smaller than the zip, and more "native" to Linux;

6. the "BSD-LICENSE.txt" and the generated HTML files have CRLF
   line endings, while the sources have LF ones. Also, the
   "configobj.txt" has LF ones, except for the HTML fragment at the
   end, that has ten CRLF endings.

I'll check issues 2. , 3a. and 3b . Let me know how to address issue 6. .

-- 
Nicola Larosa - ni...@te...

PHP is such a load of crap, right down to the standard library, that it
creates a culture where it's acceptable to write horrible code. [...]
Maybe with PHP 5 they are trying to clean up the neighborhood, but that
doesn't change the fact when you program in PHP you are programming in
a dump. -- Ian Bicking, July 2005

[Rest2web-develop] ValidateParamError

[Michael F. <mi...@pc...>]

Hello Nicola,

Note the following issue with ``ValidateParamError`` in validate.py :

    Because ``ValidateParamError`` is a subclass of ``ValidateError``,
it will
    always be trapped by ConfigObj as a failed check. Should we get
ConfigObj to
    propagate this error ? (as it is a programmer error and not a failed
check)

The easiest way to get round it is to either create a new error class
that isn't a subclass of ``ValidateError`` - or use a built in Exception.


By the way - thanks for your work on the docs.

Best Regards,

Fuzzyman

[Rest2web-develop] ConfigObj 4 Beta 1

[Michael F. <mi...@pc...>]

http://www.voidspace.org.uk/python/configobj.html
http://www.voidspace.org.uk/python/validate.html


ConfigObj 4.0.0 beta 1 and validate.py 0.2.0 are out in the wild...

A few 'niggles' to resolve, mainly in the documentation.

Things to sort include getting the sourceforge logo onto the
documentation (will happen alter today), uploading to sourceforge
(probably tomorrow), and then finishing pythonutils - over the next week
I guess.

Any comments ? - I'll probably do 'comp.lang.python.announce'ment shortly.

It would be appreciated if you could the zips and standalone files and
check they are 'unmangled' and the documentation files look ok from the
zip. I'm not at any kind of development station - so doing this myself
is a PITA.


Regards,

Fuzzball
http://www.voidspace.org.uk/python

Re: [Rest2web-develop] Docs revision, "length" removal

[Michael F. <mi...@pc...>]

Nicola Larosa wrote:
[snip..]
> 
>>I believed him without testing - hence the multitude of single trailing
>>spaces.
> 
> 
> This is quite a wide jump to conclusions. The spaces docutils does not add
> are not needed: HTML converts newlines to spaces anyway.
> 
> Didn't you wonder how it could have worked all this time without trailing
> spaces? :-)
> 

Me - no, I tend to use line wrap (wonderful invention ;-)

So docutils maintains the new line in the output HTML ? In which case
the problem that the user reports will still be a problem (despite
docutils) - which no one pointed out in the thread.

[snip..]
> 
>>>ConfigObj and validate are now ready to be moved back into the trunk, docs
>>>included, and to be released, as soon as you're satisfied with the rest of
>>>pythonutils, if you prefer releasing them together. I'd separate them,
>>>though, I think ConfigObj deserves autonomous distribution.
> 
> 
>>Yes - I'll package ConfigObj and validate for release ASAP. 
> 
> 
> That's great!
> 
> 
> 
>>I'm working towards a Pythonutils release as soon after that as possible.
> 
> 
> Will it still include ConfigObj? I suppose not.
> 

Yes - ConfigObj is an 'integral' part of pythonutils.

> 
> 
>>I'd rather be able to move the pythonutils stuff in one go. Really it
>>ought to be in it's own repository.
> 
> 
> It[no_quote]s ;-) own top directory would be enough.
> 

I'll move the whole pythonutils directory into trunk when ready.

No possessive apostrophe (quote ?) -
http://www.voidspace.org.uk/gallery/silly/bobsqu.jpg

;-) ^ 2 ?

> 
> 
>>Maybe I ought to look at setting up subversion and trac :-)
> 
> 
> That's quite a good idea. :-)
> 

Will do, possibly in 'due' course. Would be nice.

Fuzzball
http://www.voidspace.org.uk/python

Re: [Rest2web-develop] Docs revision, "length" removal

[Nicola L. <ni...@te...>]

>>> The docutils spec. seemed to indicate that a trailing (or leading) space
>>> was needed where you break a line. I freely admit to not having tested
>>> this of course !

>> Mmh... I don't remember reading anything of the sort. Docutils seems to
>> like these files just fine. The trailing spaces removal is done
>> automatically by the Kate editor, and is rather handy, since I don't
>> maintain on docs the same, rather nutty, level of white space control I do
>> on code. :-)

> There has been a very recent debate on the 'docutils-users' list about
> this. Where long lines (paragraphs) are broken by newlines - adding an
> implicit space is wrong for character sets (like the Chinese ones) that
> *don't* use spaces to separate words.

Oh, that one, didn't think it was relevant (still don't :-) ).


> David Goodger (docutils lead) thought that docutils didn't and shouldn't
> add an implicit space.

It's well and good.


> I believed him without testing - hence the multitude of single trailing
> spaces.

This is quite a wide jump to conclusions. The spaces docutils does not add
are not needed: HTML converts newlines to spaces anyway.

Didn't you wonder how it could have worked all this time without trailing
spaces? :-)


> (Oh, by the way - apparently O'Reilly are bringing out a book on Twisted.
> I saw via a Daily-Python post).

Yeah, there was an announcement on the Twisted mailing list a few weeks ago.


>> (Those "from ... import *" are ugly!)

> I'm implementing __all__ in all the sub-modules. They're there so you can
> import directly from the ``pythonutils`` namespace.

Oh yes, one of the few legitimate uses of it Silly me. :-)


>> ConfigObj and validate are now ready to be moved back into the trunk, docs
>> included, and to be released, as soon as you're satisfied with the rest of
>> pythonutils, if you prefer releasing them together. I'd separate them,
>> though, I think ConfigObj deserves autonomous distribution.

> Yes - I'll package ConfigObj and validate for release ASAP. 

That's great!


> I'm working towards a Pythonutils release as soon after that as possible.

Will it still include ConfigObj? I suppose not.


> I'd rather be able to move the pythonutils stuff in one go. Really it
> ought to be in it's own repository.

It[no_quote]s ;-) own top directory would be enough.


> Maybe I ought to look at setting up subversion and trac :-)

That's quite a good idea. :-)

-- 
Nicola Larosa - ni...@te...

PHP is such a load of crap, right down to the standard library, that it
creates a culture where it's acceptable to write horrible code. [...]
Maybe with PHP 5 they are trying to clean up the neighborhood, but that
doesn't change the fact when you program in PHP you are programming in
a dump. -- Ian Bicking, July 2005

Re: [Rest2web-develop] Docs revision, "length" removal

[Michael F. <mi...@pc...>]

Hello Nicola (and others),

-----Original Message-----
   >From: "Nicola Larosa"<ni...@te...>
   >Sent: 21/08/05 11:08:39
   >To: "res...@li..."<res...@li...>
   >Subject: Re: [Rest2web-develop] Docs revision, "length" removal
   >
   >>> Completed revising configobj.txt, committed it in two steps: in the first
   >>> one there's only trailing spaces removal, the real changes are in the
   >
   >> The docutils spec. seemed to indicate that a trailing (or leading) space
   >> was needed where you break a line. I freely admit to not having tested
   >> this of course !
   >
   >Mmh... I don't remember reading anything of the sort. Docutils seems to
   >like these files just fine. The trailing spaces removal is done
   >automatically by the Kate editor, and is rather handy, since I don't
   >maintain on docs the same, rather nutty, level of white space control I do
   >on code. :-)
   >
There has been a very recent debate on the 'docutils-users' list about this. Where long lines (paragraphs) are broken by newlines - adding an implicit space is wrong for character sets (like the Chinese ones) that *don't* use spaces to separate words.

David Goodger (docutils lead) thought that docutils didn't and shouldn't add an implicit space.

I believed him without testing - hence the multitude of single trailing spaces.

(Oh, by the way - apparently O'Reilly are bringing out a book on Twisted. I saw via a Daily-Python post).

   >
[snip...]
   >> As I mention in my other email - I've been working on the other
   >> pythonutils modules and their docs.
   >
   >Not enough time to work on those too, at the moment. :-(
   >

No - problem didn't expect your help on this.

   >
   >>> What do you think?
   >
   >> Ok - fine with me. Just do appropriate changes in docstrings/docs. I'm
   >> sure you would have anyway.
   >
   >Of course. Made the changes to code, docstrings and docs, and committed:
   >"length" is no more. :-) I also removed a leftover caseless import in
   >__init__.py . (Those "from ... import *" are ugly!)
   >

I'm implementing __all__ in all the sub-modules. They're there so you can import directly from the ``pythonutils`` namespace.

   >ConfigObj and validate are now ready to be moved back into the trunk, docs
   >included, and to be released, as soon as you're satisfied with the rest of
   >pythonutils, if you prefer releasing them together. I'd separate them,
   >though, I think ConfigObj deserves autonomous distribution.
   >

Yes - I'll package ConfigObj and validate for release ASAP. 

I'm working towards a Pythonutils release as soon after that as possible.

I'd rather be able to move the pythonutils stuff in one go. Really it ought to be in it's own repository.

Maybe I ought to look at setting up subversion and trac :-)

   >BTW, validate.py in the branch is long more than double the one in the
   >trunk, because of all those doctests. Instead, configobj.py in the branch
   >is *shorter* than the one in the trunk (v.3), *despite* all the added
   >doctests, which is remarkable. :-)
   >

Yeah - it's very good. Cutting out ``writein`` helped - but the core parser in version 3 was character by character, so pretty heavy duty.

Best Regards, 


Fuzzyman 
http://www.voidspace.org.uk/python 

   >-- 
   >Nicola Larosa - ni...@te...
   >
   >PHP is such a load of crap, right down to the standard library, that it
   >creates a culture where it's acceptable to write horrible code. [...]
   >Maybe with PHP 5 they are trying to clean up the neighborhood, but that
   >doesn't change the fact when you program in PHP you are programming in
   >a dump. -- Ian Bicking, July 2005
   >
   >
   >
   >-------------------------------------------------------
   >SF.Net email is Sponsored by the Better Software Conference & EXPO
   >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
   >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
   >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
   >_______________________________________________
   >Rest2web-develop mailing list
   >Res...@li...
   >https://lists.sourceforge.net/lists/listinfo/rest2web-develop
   >
   >

Re: [Rest2web-develop] Docs revision, "length" removal

[Nicola L. <ni...@te...>]

>> Completed revising configobj.txt, committed it in two steps: in the first
>> one there's only trailing spaces removal, the real changes are in the

> The docutils spec. seemed to indicate that a trailing (or leading) space
> was needed where you break a line. I freely admit to not having tested
> this of course !

Mmh... I don't remember reading anything of the sort. Docutils seems to
like these files just fine. The trailing spaces removal is done
automatically by the Kate editor, and is rather handy, since I don't
maintain on docs the same, rather nutty, level of white space control I do
on code. :-)


>> second one. This way it may be easier reviewing the changes. Now I'm
>> looking at validate.txt .

> Great - are you making big changes ?

Many small changes, mostly.


> I made a few changes myself - but they should be easy enough to merge.
> 
> Nice one - thanks.
> 
> As I mention in my other email - I've been working on the other
> pythonutils modules and their docs.

Not enough time to work on those too, at the moment. :-(


>> What do you think?

> Ok - fine with me. Just do appropriate changes in docstrings/docs. I'm
> sure you would have anyway.

Of course. Made the changes to code, docstrings and docs, and committed:
"length" is no more. :-) I also removed a leftover caseless import in
__init__.py . (Those "from ... import *" are ugly!)

ConfigObj and validate are now ready to be moved back into the trunk, docs
included, and to be released, as soon as you're satisfied with the rest of
pythonutils, if you prefer releasing them together. I'd separate them,
though, I think ConfigObj deserves autonomous distribution.

BTW, validate.py in the branch is long more than double the one in the
trunk, because of all those doctests. Instead, configobj.py in the branch
is *shorter* than the one in the trunk (v.3), *despite* all the added
doctests, which is remarkable. :-)

-- 
Nicola Larosa - ni...@te...

PHP is such a load of crap, right down to the standard library, that it
creates a culture where it's acceptable to write horrible code. [...]
Maybe with PHP 5 they are trying to clean up the neighborhood, but that
doesn't change the fact when you program in PHP you are programming in
a dump. -- Ian Bicking, July 2005

RE: [Rest2web-develop] Docs revision, "length" removal

[Michael F. <mi...@pc...>]

Hello Nicola,


-----Original Message-----
   >From: "Nicola Larosa"<ni...@te...>
   >Sent: 21/08/05 09:57:04
   >To: "res...@li..."<res...@li...>
   >Subject: [Rest2web-develop] Docs revision, "length" removal
     >Completed revising configobj.txt, committed it in two steps: in the first
   >one there's only trailing spaces removal, the real changes are in the

The docutils spec. Seemed to indicate that a trailing (or leading) space was needed where you break a line. I freely admit to not having tested this of course !

   >second one. This way it may be easier reviewing the changes. Now I'm
   >looking at validate.txt .
   >

Great - are you making big changes ?

I made a few changes myself - but they should be easy enough to merge.

Nice one - thanks.

As I mention in my other email - I've been working on the other pythonutils modules and their docs.

   >I'd like to remove the "length" argument for lists (and strings). It's
   >redundant (one may set "min" and "max" to the same value), and probably it
   >isn't used often to warrant special-casing it.
   >
   >Moreover, it prevents being able to write "list(1)" or "list(1,4)", forcing
   >explicit specification: "list(min=1)", "list(min=1, max=4)", and making it
   >incoherent with "integer" check definition.
   >
   >What do you think?
   >

Ok - fine with me. Just do appropriate changes in docstrings/docs. I'm sure you would have anyway.

All the Best,

Fuzzyman 
http://www.voidspace.org.uk/python 

   >-- 
   >Nicola Larosa - ni...@te...
   >
   >PHP is such a load of crap, right down to the standard library, that it
   >creates a culture where it's acceptable to write horrible code. [...]
   >Maybe with PHP 5 they are trying to clean up the neighborhood, but that
   >doesn't change the fact when you program in PHP you are programming in
   >a dump. -- Ian Bicking, July 2005
   >
   >
   >
   >   >

[Message truncated. Tap Edit->Mark for Download to get remaining portion.]

[Rest2web-develop] Docs revision, "length" removal

[Nicola L. <ni...@te...>]

Completed revising configobj.txt, committed it in two steps: in the first
one there's only trailing spaces removal, the real changes are in the
second one. This way it may be easier reviewing the changes. Now I'm
looking at validate.txt .

I'd like to remove the "length" argument for lists (and strings). It's
redundant (one may set "min" and "max" to the same value), and probably it
isn't used often to warrant special-casing it.

Moreover, it prevents being able to write "list(1)" or "list(1,4)", forcing
explicit specification: "list(min=1)", "list(min=1, max=4)", and making it
incoherent with "integer" check definition.

What do you think?

-- 
Nicola Larosa - ni...@te...

PHP is such a load of crap, right down to the standard library, that it
creates a culture where it's acceptable to write horrible code. [...]
Maybe with PHP 5 they are trying to clean up the neighborhood, but that
doesn't change the fact when you program in PHP you are programming in
a dump. -- Ian Bicking, July 2005

Re: [Rest2web-develop] None and Defaults

[Michael F. <mi...@pc...>]

Hello Nicola,

-----Original Message-----
   >From: "Nicola Larosa"<ni...@te...>
   >Sent: 16/08/05 21:35:34
...
   >
   >> I'm -1 on moving/removing Section/ConfigObj attributes.
   >> 
   >> I don't *mind* leaving attribute access in - but I don't like it
   >> especially.
   >
   >No, not in this shape. Too messy, too much guesswork. Did it work whis way
   >in v.3 too?
   >

Yes it was for convenience, mainly just because it's how other packages do it. They get round the problem (I think) by using functions rather than methods or providing getters and setters. Neither are particularly pythonic.

Fuzzball

   >Ok, take it away, I'll cope.
   >
   >-- 
   >Nicola Larosa - ni...@te...
   >
   >Python is the best thing I've seen in 30 years of computing for
   >pedogogical and productive purposes. Only when I want speed do I
   >see a need for something else. -- Chuck Allison, June 2005
   >
   >

[Message truncated. Tap Edit->Mark for Download to get remaining portion.]

Re: [Rest2web-develop] None and Defaults

[Nicola L. <ni...@te...>]

> This is exactly why attribute access is bad.
> 
> The object namespace is the RIGHT place. These *are* public attributes of
> the section. Are you going to move section methods to another namespace
> as well ? (a rhetorical question).

Very good point.


> I'm -1 on moving/removing Section/ConfigObj attributes.
> 
> I don't *mind* leaving attribute access in - but I don't like it
> especially.

No, not in this shape. Too messy, too much guesswork. Did it work whis way
in v.3 too?

Ok, take it away, I'll cope.

-- 
Nicola Larosa - ni...@te...

Python is the best thing I've seen in 30 years of computing for
pedogogical and productive purposes. Only when I want speed do I
see a need for something else. -- Chuck Allison, June 2005