Thread: [Rest2web-develop] ConfigObj 4 Beta 1
Brought to you by:
mjfoord
From: Michael F. <mi...@pc...> - 2005-08-23 08:25:29
|
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 |
From: Nicola L. <ni...@te...> - 2005-08-24 07:00:20
|
> 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 |
From: Michael F. <mi...@pc...> - 2005-08-24 07:32:09
|
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 |
From: Nicola L. <ni...@te...> - 2005-08-24 09:00:18
|
>> 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 |
From: Nicola L. <ni...@te...> - 2005-08-25 08:33:00
|
> 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 |
From: Michael F. <mi...@pc...> - 2005-08-25 08:48:05
|
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 |
From: Michael F. <mi...@pc...> - 2005-08-25 13:08:20
|
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 |