Re: [Python-Dev] xml.etree.ElementTree.IncrementalParser (was: ElementTree iterparse string)
Hi, Le Thu, 08 Aug 2013 06:33:42 +0200, Stefan Behnel a écrit : > [from python-ideas] > > Antoine Pitrou, 07.08.2013 08:04: > > Take a look at IncrementalParser: > > http://docs.python.org/dev/library/xml.etree.elementtree.html#incremental-parsing > > Hmm, that seems to be a somewhat recent addition (April 2013). I > would have preferred hearing about it before it got added. > > I don't like the fact that it adds a second interface to iterparse() > that allows injecting arbitrary content into the parser. > You can now > run iterparse() to read from a file, and at an arbitrary iteration > position, send it a byte string to parse from, before it goes reading > more data from the file. Or take out some events before iteration > continues. > > I think the implementation should be changed to make iterparse() > return something that wraps an IncrementalParser, not something that > is an IncrementalParser. That sounds reasonable. Do you want to post a patch? :-) > Also, IMO it should mimic the interface of the TreeBuilder, which > calls the data reception method "data()" and the termination method > "close()". There is no reason to add yet another set of methods names > just to do what others do already. Well, the difference here is that after calling eof_received() you can still (and should) call events() once to get the last events. I think it would be weird if you could still do something useful with the object after calling close(). Also, the method names are not invented, they mimick the PEP 3156 stream protocols: http://www.python.org/dev/peps/pep-3156/#stream-protocols Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The Return Of Argument Clinic
On 08/05/2013 09:59 PM, Nick Coghlan wrote: ___ Question 2: Emit code for modules and classes? [...] Originally Clinic didn't ask for full class and module information, you just specified the full dotted path and that was that. But that's ambiguous; Clinic wouldn't be able to infer what was a module vs what was a class. And in the future, if/when it generates module and class boilerplate, obviously it'll need to know the distinction. [...] Note that setuptools entry point syntax solves the namespace ambiguity problem by using ":" to separate the module name from the object's name within the module (the nost test runner does the same thing). I'm adopting that convention for the PEP 426 metadata, and it's probably appropriate as a concise notation for clinic as well. So you're proposing that xml.etree.ElementTree.dump() be written as "xml.etree:ElementTree.dump", and datetime.datetime.now() be written as "datetime:datetime.now"? And presumably *not* specifying a colon as part of the name would be an error. ___ Question 5: Keep too-magical class decorator Converter.wrap? You misunderstand me: I believe a class decorator is the *wrong solution*. I am saying Converter.wrap *shouldn't exist*, and that the logic for what it does should be directly in Converter.__init__. Well, nobody liked it, everybody hated it, so I'll go with what you proposed, though with the name converter_init() for the custom converter init function. //arry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The Return Of Argument Clinic
On 8 Aug 2013 02:48, "Larry Hastings" wrote: > > On 08/05/2013 09:59 PM, Nick Coghlan wrote: >>> >>> ___ >>> Question 2: Emit code for modules and classes? >>> >>> [...] Originally Clinic didn't ask for full class and module information, you just >>> specified the full dotted path and that was that. But that's ambiguous; >>> Clinic wouldn't be able to infer what was a module vs what was a class. And >>> in the future, if/when it generates module and class boilerplate, obviously >>> it'll need to know the distinction. [...] >> >> Note that setuptools entry point syntax solves the namespace ambiguity >> problem by using ":" to separate the module name from the object's >> name within the module (the nost test runner does the same thing). I'm >> adopting that convention for the PEP 426 metadata, and it's probably >> appropriate as a concise notation for clinic as well. > > > So you're proposing that xml.etree.ElementTree.dump() be written as "xml.etree:ElementTree.dump", and datetime.datetime.now() be written as "datetime:datetime.now"? And presumably *not* specifying a colon as part of the name would be an error. Assuming there's no way to tell argument clinic all the functions and classes in a given C file belong to the same module, then yes, you would need the colon in every name to indicate the module portion. > > >>> ___ >>> Question 5: Keep too-magical class decorator Converter.wrap? >> >> You misunderstand me: I believe a class decorator is the *wrong >> >> solution*. I am saying Converter.wrap *shouldn't exist*, and that the >> logic for what it does should be directly in Converter.__init__. > > > Well, nobody liked it, everybody hated it, so I'll go with what you proposed, though with the name converter_init() for the custom converter init function. My future code-reading self thanks you :) Cheers, Nick. > > > /arry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
