<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 2, 2013 at 1:24 AM, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le Sun, 1 Sep 2013 18:02:30 -0700,<br>
Eli Bendersky <<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>> a écrit :<br>
<div class="im">> Hello,<br>
><br>
> I was looking at the possibility of replacing the SEEK_* constants by<br>
> IntEnums, and the first thing that catches attention is that these<br>
> constants are defined in both Lib/os.py and Lib/io.py; both places<br>
> also recently started supporting SEEK_HOLE and SEEK_DATA (though here<br>
> io refers to os.SEEK_HOLE and os.SEEK_DATA).<br>
<br>
</div>What is the runtime cost of doing so? os is a fundamental module that is<br>
imported by almost every Python program.<br></blockquote><div><br></div><div>Theoretically, it should be very low given that we just need to add an import and define one class. os already does a number of things in its toplevel (mostly a few imports which transitively do other things). Compounded with import caching, since this is done just once per run, doesn't seem like a problem.<br>

<br>Empirically, I tried measuring it but I can't discern a difference with/without translating SEEK_* to enums. There's a fluctuation of ~1usec which I can't distinguish from noise. Let me know if you have a good methodology of benchmarking these things<br>

<br>Eli<br><br> <br></div></div><br></div></div>