On Fri, Jan 04, 2008 at 02:54:49PM -0800, Guido van Rossum wrote: > What code would break if we loosened this restriction? I guess > defining d.items() as zip(d.keys(), d.values()) would no longer fly, > but does anyone actually depend on this? Just like we changed how we
http://www.google.com/codesearch?hl=en&q=+lang:python+zip+keys&start=10&sa=N turns up a few pieces of code that would break: trac-0.10.3/trac/versioncontrol/cache.py Twisted-2.2.0/twisted/pb/test/test_banana.py Mattricks-0.7/Mattricks/MatchPrediction.py FlickrUploadr-1.0.0/src/xmltramp.py Projects trying to stay compatible with Python versions that don't have .items() may be more likely to use this idiom. Some classes may do this to implement .items(); openbabel-2.1.1/scripts/python/pybel.py does this. So some code will break, and I don't see a way to warn about this problem before breaking compatibility. --amk _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com