Re: [Python-Dev] Wishlist: dowhile
On Monday 13 June 2005 08:07, Nick Coghlan wrote: > Raymond Hettinger wrote: > > [BJörn Lindqvist] > > > >>I would like to have do-while's like this: > >> > >>do: > >> > >>until > >> > >>But I'm sure that has problems too. > > > > That looks nice to me. > > And this could easily be extended to allow code both before and after > the 'until', giving a fully general loop: > >do: > >until > >else: > > > In fact, this would simply be giving "looks like executable > pseudocode" syntactic sugar for the current 'do-until' workarounds: > >while 1: > > if : > > break > Yet another way to spell this would be make the default for the while statement be true so the 1 could be omitted and then add a condition to break. while: break : I think this would be feature creep. It complicates the language for a very small gain. While the added syntax would be intuitive, it only saves a line or two over the existing syntax. ___ 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] Sharing expat instances
On Tuesday 13 December 2005 17:17, Fredrik Lundh wrote: > the remaining issue is how to include cElementTree. the current stand- > alone distribution consists of a single cElementTree module, which is in- > stalled under site-packages, as usual. > > to avoid collisions, it's probably best to install the bundled version > under xml.etree, but how do you do that for a C module ? > > my current idea is to > > 1. include it under a different name (_elementtree.so) > > 2. add a cElementTree.py under xml.etree, which simply does > > from _elementtree import * > > does anyone have a better idea ? Avoiding imaginaary name collisions and putting cElementTree into the xml package is making the task harder than need be and will perpetuate the problems caused by the earlier decision to do magic in the xml import statement. The use of magic was a violation of "explicit is better than implicit". Forgeting this rule has caused pain to many people who didn't expect a magic side effects from simply installing PyXML. Adding cElementTree to the mess that already exists doessn't make sense, and the only justification for not adding a new top level package seems to be to avoid an imaginary potential for name collisions. Why repeat the mistake of PyXML simply to have all the xml software in the same top level package? Perhaps if this were a common practice in the stdlib it might make sense. For instance, if there were a gui.Tkinter and a gui.PyGtk and a gui.wxPython it might look more consistent. Who is pushing to put all xml software inside the xml package? Collisions with names of a top level import statement are rare and Python has supports renaming in the rare event that someone did need to rename the module. import etree as stdetree. I would like the cElementTree version of the package have a shorter name. For example etree. The Python implementation could continue to be named ElementTree or shorten it to pyetree. The cElementTree version will probably be the most frequently used since it is faster, so why not make it's name short. One final addition would be to include a "See Also" reference to the new etree and pyetree modules in the introduction of the xml package. ___ 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] Sharing expat instances
On Wednesday 14 December 2005 01:05, Fredrik Lundh wrote: > Michael McLay wrote: > > Avoiding imaginaary name collisions and putting cElementTree into the xml > > package > > there's nothing imaginary here -- cElementTree is an existing and quite > popular module, and will remain available as a separate distribution. > > it would be nice if people could install that kit also under 2.5 without > risking to mess up their Python installation. > > (another solution would of course to rule out use of cElementTree by > modules shipped with Python...) Renaming the cElementTree in the standard distribution to etree would elmiinate collisions with the existing cElementTree. A few other names to consider would be xmltree or xmlTree. Or, if the consensus is to keep it in the xml package, the name could still be shorted to calling it xml.tree. Average name lengths in the standard distribution are getting longer. In some cases the longer names are very helpful when browsing the module index. For instance, the function of SimpleXMLRPCServer is immediately apparent. To me, the purpose of a package named ElementTree isn't as apparent. While there is value in having meaningful names, there is also an advantage in having names short for commonly used tools. Imagine how painful it would be to type Operatingsystem instead of os. The name xmltree would be shorter and as descriptive as xml.cElementTree. The name etree would be shorter, but less descriptive. ___ 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] Website cruft
The download page http://www.python.org/download/ has a reference to "CVS Access" http://www.python.org/download/cvs.html that references a page with pointers to the old SourceForge CVS. Would someone please update these pages to reflect the move to Subversion. ___ 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
