Author scoder
Recipients eli.bendersky, flox, jcea, pitrou, python-dev, scoder
Date 2013-08-09.14:44:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1376059455.74.0.132545766525.issue17741@psf.upfronthosting.co.za>
In-reply-to
Content
> But worse than no change at all. Arguing about API naming is a bit
> futile, *especially* when the ship has sailed.

<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.

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? Why should the type of the *result* of the parsing process change the method name that you need to call to *insert* data into the parser?
History
Date User Action Args
2013-08-09 14:44:15scodersetrecipients: + scoder, jcea, pitrou, eli.bendersky, flox, python-dev
2013-08-09 14:44:15scodersetmessageid: <1376059455.74.0.132545766525.issue17741@psf.upfronthosting.co.za>
2013-08-09 14:44:15scoderlinkissue17741 messages
2013-08-09 14:44:15scodercreate