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 rhettinger
Recipients mjpieters, rhettinger
Date 2017-05-09.09:01:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1494320492.07.0.374795494837.issue30293@psf.upfronthosting.co.za>
In-reply-to
Content
Looking back at the OP's timings in the referenced SO question, I would expect that if someone "fixed" this issue, it wouldn't be long before someone else filed a performance regression bug claiming a 63,000x slowdown in exactly the same code.

I'm marking this as closed because if this ever did arise in real code, it is unclear whether the desirable behavior is to eat memory but run fast, or to save memory upfront but run dog slow and eat memory later when the function is called.  Either way, the situation is likely to be very rare.

Your guess is as good as mine regarding which behavior would be more desirable to the user.  Presumably, if they direct the computer to build a large object, they won't be surprised if a large object is created.
History
Date User Action Args
2017-05-09 09:01:32rhettingersetrecipients: + rhettinger, mjpieters
2017-05-09 09:01:32rhettingersetmessageid: <1494320492.07.0.374795494837.issue30293@psf.upfronthosting.co.za>
2017-05-09 09:01:32rhettingerlinkissue30293 messages
2017-05-09 09:01:31rhettingercreate