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 terry.reedy
Recipients ezio.melotti, guido.reina, serhiy.storchaka, terry.reedy
Date 2013-02-15.22:10:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1360966202.49.0.379937192151.issue17183@psf.upfronthosting.co.za>
In-reply-to
Content
'Enhancement' issues are for visible behavior additions (or occasionally, changes). This is intended to be an invisible small speedup, hence it is a 'performance' issue, and gets a different title.

As explained in #17170, the change will not be a speedup if the substring being looked for is usually not there. The reason is the .find lookup and function call versus the direct syntax. Even if it is faster, I strongly doubt it would be hardly noticeable in the context of this function, which itself is a small piece of parsing an entire document, and it is against our policy to make such micro-optimizations in working code.

The complete block in question Lib/_markupbase.py, 254:7 is

  rawdata = self.rawdata
  if '>' in rawdata[j:]:
    return rawdata.find(">", j) + 1
  return -1

[Ugh. Localizing rawdata negates some of whatever advantage is gained from the double scan.]

If I were to rewrite it, I would replace it with

  try:
    return self.rawdata.index(">", j) + 1
  except ValueError:
    return -1

as better style, and a better example for readers, regardless of micro speed differences. But style-only changes in working code is also against our policy. So I would be closing this if Ezio had not grabbed it ;-).
History
Date User Action Args
2013-02-15 22:10:02terry.reedysetrecipients: + terry.reedy, ezio.melotti, serhiy.storchaka, guido.reina
2013-02-15 22:10:02terry.reedysetmessageid: <1360966202.49.0.379937192151.issue17183@psf.upfronthosting.co.za>
2013-02-15 22:10:02terry.reedylinkissue17183 messages
2013-02-15 22:10:01terry.reedycreate