Antoine Pitrou added the comment: > <rant>It's easy to say that as a core developer with commit rights > who can simply hide changes in a low frequented bug tracker without > notifying those who have to know about these changes.</rant> It's > pure luck I noticed this change during the alpha release cycle.
It is the rule for most stdlib improvements that they go directly through the bug tracker. Most core developers and outsiders would feel swamped by the traffic if all feature additions went through the mailing-list. I'm honestly baffled that you think I am trying to "hide" things. Why do you think I would feel guilty about proposing an addition, or try to sneak things inside xml.etree? (yes, we could theoretically run polls for every addition we propose, collect and discuss the results, and iterate several times until the outcome is successful; I don't think any of us has the bandwidth to do that, which is why that practice is only used for game-making changes (i.e. PEP material)) > I'm also not arguing about naming. I'm questioning the design, trying > to get it into a shape that fits the existing APIs. Why do we need > two incremental parsing interfaces in one and the same library that > use completely different method names, although doing otherwise > exactly the same? Well, unless I'm missing something, TreeBuilder doesn't do parsing, it takes already parsed data: it has a start() method to open a tag, and a data() method to add raw text inside that tag. IncrementalParser, OTOH, has a data_received() method to which you pass a piece of non-parsed XML string. The other incremental parsing API is actually iterparse(). The reason I proposed IncrementalParser is that iterparse() is useless for non-blocking applications. IncrementalParser produces the same kind of output as iterparse(), but control of when to feed it data is transferred to the user of the API. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17741> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
