Message 284909 - Python tracker

Message284909

Author	xiang.zhang
Recipients	Yury.Selivanov, belopolsky, methane, ncoghlan, serhiy.storchaka, vstinner, xiang.zhang, yselivanov
Date	2017-01-07.11:58:57
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1483790338.04.0.541796902294.issue29178@psf.upfronthosting.co.za>
In-reply-to

Content
I'm -1 if the intention is about easiness and efficiency. I think a new API is usually added due to functional defect not performance defect. We get a way here though the performance seems not ideal, according to INADA's mail. I think we should first check if memoryview gets an optimization chance to fit more in such a case. Creating a memoryview is not cheap enough in such a case. About easiness to use, when a user considering such low level details, it's reasonable to know memoryview and it needs to be released. But if this API is added to simplify bytes(), I think it makes sense but it's not only about adding a frombuffer().

Content

I'm -1 if the intention is about easiness and efficiency. 

I think a new API is usually added due to functional defect not performance defect. We get a way here though the performance seems not ideal, according to INADA's mail. I think we should first check if memoryview gets an optimization chance to fit more in such a case. Creating a memoryview is not cheap enough in such a case.

About easiness to use, when a user considering such low level details, it's reasonable to know memoryview and it needs to be released.

But if this API is added to simplify bytes(), I think it makes sense but it's not only about adding a frombuffer().

History
Date	User	Action	Args
2017-01-07 11:58:58	xiang.zhang	set	recipients: + xiang.zhang, ncoghlan, belopolsky, vstinner, methane, Yury.Selivanov, serhiy.storchaka, yselivanov
2017-01-07 11:58:58	xiang.zhang	set	messageid: <1483790338.04.0.541796902294.issue29178@psf.upfronthosting.co.za>
2017-01-07 11:58:58	xiang.zhang	link	issue29178 messages
2017-01-07 11:58:57	xiang.zhang	create