>Tom, > >I'd like to see classes and methods similar to the ones in the >existing modules (wms.py etc), providing the same interfaces. For >example > > class CatalogService: > """instead of request""" > > def getrecord(self): > """instead of GetCapabilities""" >
Done. >This is also more in line with Python PEP 8, capitalized class names, >lowercase method names. Any service should have a "capabilities" >property. See the wms.py, wfs.py, and wcs.py modules. > >Importing etree from owslib.etree tries lxml and then falls back on >elementtree or xml.etree, so do that instead of depending only on lxml. > It looks like lxml is tested last, no? Here's where I'm falling down: if lxml proper is not used, the namespace support breaks, especially when constructing the XML message required for HTTP POST to a CSW. Using elementtree or xml.etree, I haven't found a way (or examples) to construct valid XML requests. Here's an example: http://devgeo.cciw.ca/cat/GeneralQuery1.xml Any suggestions? >Pedantic me, I can not abide the name "fetch" for a method that makes >an HTTP POST request ;) GET is the HTTP method with fetch semantics. >Call it "_doRequest" or something. Probably shouldn't be part of the >public API. > Done. >Lastly, let's get some tests in there soon. > In the same way as wms/wfs/sos, right? Putting in docstrings right in the classes might bloat the code (responses can be big). >I hope you don't mind the review. I just wanted to point out some >little things. Not at all! Thanks alot for your advice and irc help! Much appreciated. I haven't committed the updates yet, pending discussion on the lxml issue. ..Tom _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
