Re: [Python-Dev] FWD: Documentation site problems
there contents is missing from the python tutorial: The 3.0 docs seem to be correct: http://docs.python.org/3.0/tutorial/ It seems it is not the case anymore. The devel doc from Python 3 are missing a few tables of contents as well: http://docs.python.org/dev/py3k/tutorial/ When I build the html doc locally, it looks like Sphinx from svn (r68598) has an issue with the 'numbered' option in the toctree directive. Here is my output of `make html' from revision 71295 of the py3k branch: http://fourmanoit.googlepages.com/pydoc_output.txt It did work fine a few days back though -- yesterday, the online doc was still complete: I believe it was last built on March the 28th. Yours, -- Sylvain Fourmanoit Memory fault -- core...uh...um...core... Oh dammit, I forget! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New miniconf module
I wrote a data persistence module called miniconf, aimed at making easy to create and safely retrieve configuration info from external, human-readable sources using Python syntax. I feel it would eventually make a nice addition to the standard library. The code was only newly refactored in this form, but it as been broadly distributed and used as a part of the adesklets project for over a year by a significant user base on multiple platforms. Here it is, as a patch against Python 2.5 SVN tree[1], or as a stand-alone module hosted on the Python Cheese Shop[2]; any feedback is welcomed. -- Sylvain <[EMAIL PROTECTED]> Hackers are just a migratory lifeform with a tropism for computers. [1]http://sourceforge.net/tracker/index.php?func=detail&aid=1527597&group_id=5470&atid=355470 [2]http://cheeseshop.python.org/pypi?:action=display&name=miniconf&version=1.0.1 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New miniconf module
> miniconf, OTOH, appears to have an interface compatible with capability > security (I have not checked that the compiler.ast module used in its > implementation is safe.) I woudn't be 100% sure either (obviously, I didn't write this nice piece of code, let alone the underlying parser), but I read it and tried to abuse it without success (I haven't found obvious buffer overflow and such)... As far as I know, the abstract syntax tree generation exposed via compiler.ast is a safe operation, in the sense that it doesn't allow execution of code when feeded from arbitrary strings via compiler.parse(); in the worst case scenario, it raises a SyntaxError or similar exceptions, as documented... If anybody know more on this issue, I will be happy to hear about it. > miniconf has a few limitations one should be aware of: > > - It is not preemptiple: concurrent calls to dump() or load() will > have unpredictable results and must be avoided. > > This limitation should be fixed before the module is added to the > standard library, IMHO. If this is the general opinion, I will be glad to change this... The only reason miniconf is not thread-safe for the moment is that I chose to re-use over and over a single instance of each of my two processing classes to reduce resources usage, but this seems pretty pointless (and overly complicated) now that I look at it. Yours, -- Sylvain <[EMAIL PROTECTED]> Your files are now being encrypted and thrown into the bit bucket. EOF ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New miniconf module
> It looks like it's trivial to fix; the code uses a strange and > unnecessary complication of creating nested classes and nested > singleton instances thereof. Getting rid of the singletons to create a > new instance for each dump/load call would suffice to make the > implementation re-entrant, although de-nesting the classes would also be > a good idea. :) OK then, I will change this. > The loading code could also be made a lot faster by using a dictionary > mapping AST node types to functions, instead of doing string > manipulation for each node. Each function could take 'pedantic' as a > parameter, which would eliminate the need to have an object at all, let > alone a singleton. > I am not convinced the current string manipulation for mapping the nodes types to the methods of the _Load class has such a significant impact on performance, but I will test your suggestion... The only difference with current code is that we use a dynamically computed string as the dictionary key to locate the function instead of the node type themselves as keys. > Finally, there is an interesting characteristic of the code's > interpretation of names: any name other than 'True' is interpreted as > 'False'! ;-) It will be corrected in the next release. > On the whole, though, I don't see a lot of difference between this format > and say, JavaScript Object Notation (JSON), which can be parsed and > generated by many other languages as well as multiple Python libraries > already. The difference is that this is Python code, already familiar to all Python coders... Besides, it sits directly on top of the real Python parser, mitigating the need of a new one, and keeping the added code complexity to a strict minimum. But I agree this looks a lot like JSON, since ecmascript syntax for literals looks a lot like the one of Python... For the same reasons there is a need for JSON, I think having something like miniconf in the standard lib would benefit the users. -- Sylvain <[EMAIL PROTECTED]> If you think the system is working, ask someone who's waiting for a prompt. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New miniconf module
An updated version is now available, based to the feedback of Phillip J.
Eby and David Hopwood (stand-alone module[1], patch[2]):
- the module is now reentrant
- the sloppy case with Name nodes is now covered properly
- the node lookup procedure was optimized, leading to a 20% speed
increase on the average case... Phillip, I was wrong to doubt you. ;-)
There is undoubtedly still room from improvement, but that's a good start.
>> But I agree this looks a lot like JSON, since ecmascript syntax for
>> literals looks a lot like the one of Python... For the same reasons there
>> is a need for JSON, I think having something like miniconf in the
>> standard lib would benefit the users.
>
> Actually, I would see more reason to include JSON in the standard library,
> since it's at least something approaching an internet protocol these days.
Having JSON there would indeed be nice: In fact, I recall being initially
surprised it was not supported by the standard library.
But is there a need to choose? Why not have both? The miniconf approach
has its advantages and differences:
- The code is short and simple. Since all the real work is performed by
the Python parser, very little has to be done on top of that: it should be
easy to maintain, and will benefit of all the future work (patches, etc.)
that will be integrated to it in the future.
- The source it works on is valid Python source, which seems to be a plus
for a dynamic, reflexive language such as Python... Things such as this
will work:
>>> from miniconf import dump
>>> file('test.py','w').write(dump({'spam': 1}))
>>> import test
I know this in not the best example, but you get the idea...
- Unlike JSON, miniconf is not introducing any new notation or syntax at
all: it uses a strict, well defined subset of the Python grammar that
every Python user is already familiar with; it is in no way a
data-interchange format, but it feels pretty natural in a all-python
environment... In that sense, it is well documented and standardized.
- Am I missing something, or is JSON not supporting comments inside the
parse tree? That's not really convenient for storage of configuration
information.
Anyway, if I had to choose between the two, I would definitively want
simplejson part of the standard library well before miniconf, since it can
be used in so many different situations, but I wouldn't
choose JSON as a configuration format given the choice to use the Python
notation employed by miniconf either.
Yours,
--
Sylvain <[EMAIL PROTECTED]>
Nobody said computers were going to be polite.
[1]http://cheeseshop.python.org/pypi?:action=display&name=miniconf&version=1.1.0
[2]http://sourceforge.net/tracker/index.php?func=detail&aid=1527597&group_id=5470&atid=355470
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New miniconf module
Armin Rigo wrote: > In the same spirit, maybe it could be slightly re-oriented towards a > dumper/loader for more than config files; for example, it could provide > a safe inverse of repr() for common built-in types New version of miniconf (version 1.2.0) is out [1][2], including a unrepr() function; that's the only change this time. Michael Foord wrote: > ConfigObj [3] gained an 'unrepr' mode a while back. The code is simple, > and originally came from CherryPy. Thanks for the link! I completely missed ConfigObj. It indeed shares a lot with my code. At the core, it use many of the same ideas and implementation techniques... In many ways, it is also a lot more advanced, specialized than miniconf: for instance, it introduce a new, specialized Config File format, while my effort aimed at keeping things minimal. Armin Rigo wrote: > If it goes in that direction, I'd suggest to rename the module to give > it a name closer to existing persistence-related modules already in the > stdlib. I am not especially fond of the current miniconf name either; I didn't find something more suitable, yet evocative of what it does; I would be glad to hear any suggestion you or the rest of the developers would have. Yours, -- Sylvain <[EMAIL PROTECTED]> The only difference between a car salesman and a computer salesman is that the car salesman knows he's lying. [1]http://cheeseshop.python.org/pypi?:action=display&name=miniconf&version=1.2.0 [2]http://sourceforge.net/tracker/index.php?func=detail&aid=1527597&group_id=5470&atid=355470 [3]http://www.voidspace.org.uk/python/configobj.html P.-S. I am leaving the civilization (where I have some sort of network access) from July the 29th to August the 13th: I will be glad to address any comment, bug report or suggestion Python developers might want to discuss in the meantime as soon as I will be back. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reindenting the C code base?
On Sat, 13 Dec 2008, Guido van Rossum wrote: If you reindent, much of the history of the file is essentially lost -- "svn blame" will blame whoever reindented the code, and it's a pain to go back. I am not a subversion specialist, but it appears this part can be handled gracefully by passing -b (ignore space change) to an external diff command svn blame can rely on (svn blame -x -ub ...). At least, it seems to work on my station (GNU Diffutils, Subversion 1.5.1)! -- Sylvain ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
