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.

Title: max( str ) should be fast with PEP 393
Type: enhancement Stage:
Components: Interpreter Core Versions: Python 3.3
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: loewis, v+python, vstinner
Priority: normal Keywords:

Created on 2012-06-29 19:53 by v+python, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (3)
msg164351 - (view) Author: Glenn Linderman (v+python) * Date: 2012-06-29 19:53
This is stupid code, but it should be faster with PEP 393 than before, should it not?

str = ' ' * 5000000 + "this is really a string!!!";
for ix in range( 9000 ):
    z = max(str)
print("Max character: " + max(str))

While the new C API seems to support quickly finding the max character in a string, Python code does not benefit.
msg164352 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-06-29 21:09
What the C code finds quickly (in constant time) is that the maximum is <=127. Most code doesn't know (and doesn't care) what the actual maximum is. So I see no bug here.
msg164362 - (view) Author: Glenn Linderman (v+python) * Date: 2012-06-29 23:27
Ah, so then it would require a new API to make the Python code as smart as the C code, max is too general.

Issue 15016 is an example of Python code that could benefit from knowing in constant time if the string contained only characters < 128, or if the string contained only characters < 256... a three way decision.
Date User Action Args
2022-04-11 14:57:32adminsetgithub: 59431
2012-06-30 10:12:06loewissetstatus: open -> closed
resolution: not a bug
2012-06-29 23:28:21v+pythonsettype: enhancement
2012-06-29 23:27:40v+pythonsetmessages: + msg164362
2012-06-29 21:09:08loewissetnosy: + loewis
messages: + msg164352
2012-06-29 19:55:04pitrousetnosy: + vstinner
2012-06-29 19:53:25v+pythoncreate