<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 3, 2013 at 9:17 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":vk" style="overflow:hidden">Yep, this is an area where laziness is definitely a virtue - if work<br>
is only needed to handle a hypothetical future change, then it can be<br>
deferred and handled as part of that change. :)</div></blockquote></div><br>I would say that even renaming the files can wait until we actually have a conflict.  Note that reimplementing enum.py in C will not cause a conflict because that code will likely go to Modules/enum.c or Modules/_enum.c and not in Objects/enumobject.c.  If any renaming in Objects/ directory is in order, I would start with longobject.c and unicodeobject.c rather than enumobject.c.  It is fairly obvious to look for enumerate code next to range code and tab-completion gets me to the right file fairly quickly.  On the other hand, I've been trying to find intobject.c in 3.x code on more than one occasion.</div>
</div>