This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dmtr
Recipients Dima.Tisnek, alex, bls, dmtr, jafo, josh.r, mark.dickinson, martin.panter, milko.krachounov, rhettinger, tebeka, terry.reedy
Date 2015-03-07.00:44:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1425689078.47.0.473801800248.issue4356@psf.upfronthosting.co.za>
In-reply-to
Content
Use case: a custom immutable array with a large number of items and indirect key field access. For example ctypes.array, memoryview or ctypes.pointer or any other custom container.


1. I'm not sure how anyone can consider a precached key array as a right ans scalable answer. It is just a ridiculuos idea. Precashing key array is a O(N) operation.  While bisect is O(log(N)).

2. @Raymond There is a statement that "adding 'key()' would encourage bad design and steer people after from better solutions."  Well, right now, the design that is being encouraged results in O(N) code. Because lazy developers are just 'pre-cacaching' (copying) the keys!

3. There is a statement that key() have to be called multiple times per item. What?  Why?

4. There is a statement that one can always add a _cmp_ function to an object. This is ridiculuous. The object could be immutable. There should be no need to modify the object/array when all that you need to do is to bisect it.
History
Date User Action Args
2015-03-07 00:44:38dmtrsetrecipients: + dmtr, rhettinger, terry.reedy, jafo, tebeka, mark.dickinson, alex, milko.krachounov, bls, martin.panter, Dima.Tisnek, josh.r
2015-03-07 00:44:38dmtrsetmessageid: <1425689078.47.0.473801800248.issue4356@psf.upfronthosting.co.za>
2015-03-07 00:44:38dmtrlinkissue4356 messages
2015-03-07 00:44:38dmtrcreate