[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

Steve Dower added the comment: Thanks for the patch! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 -Python 3.8 ___ Python tracker

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

Steve Dower added the comment: New changeset 5907e61a8d4da6d0f11bf1062d6d17484560a15e by Steve Dower (An Long) in branch 'master': bpo-35292: Avoid calling mimetypes.init when http.server is imported (GH-17822) https://github.com/python/cpython/commit/5907e61a8d4da6d0f11bf1062d6d17484560a15e

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

Change by AnLong : -- pull_requests: +17248 pull_request: https://github.com/python/cpython/pull/17822 ___ Python tracker ___ ___

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

Change by Demian Brecht : -- nosy: +demian.brecht ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

Steve Dower added the comment: I have another idea - what if we checked self.extensions_map for overrides but otherwise just called mimetypes.guess_type(path) in the guess_type method? That would be the same behaviour as initializing it lazily, but we don't have to worry about initializing

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

Steve Dower added the comment: So, you're suggesting doing a lazy mimetypes.init() on Windows and not on the others? There's no reason to have such a semantic difference between platforms, and since the whole point of mimetypes.init() is to avoid initializing on import, it makes the most

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

pmpp added the comment: sorry i was on my free time when enumerating profiling/instrumentation and testing. given now you pay attention i'll try to explain more. instrumentation : what does that server actually support ? eg writing a test for a specific mimitype support eg

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

Steve Dower added the comment: > I agree that makes no sense at all. I have to admit I have no idea what you're trying to argue or suggesting as an alternative. Could you try clearly explaining the change you'd rather see to fix the issue? --

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

pmpp added the comment: the PR as it is actually add a blocking read (and maybe exceptions or whatever mimetypes modules decide to do) in processing of the first request to server, which has nothing to do with the code serving that request. I agree that makes no sense at all. --

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

Steve Dower added the comment: (Sorry, page submitted while I was still typing for some reason.) ... Instrumentation for everything other than time is unaffected, so if you didn't mean to conflate them, then no there is no impact on the documented use. Yes, moving mimetypes.init to the

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

Steve Dower added the comment: If you weren't conflating profiling and instrumentation then your original comment makes no sense. -- ___ Python tracker ___

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

pmpp added the comment: ??? i never compared Instrumentation and profiling and what getting delta timing about the script behind the first http request has to do with performance ? <= that's actually another question thefirst was : isn't http.server reserved for instrumentation and testing

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

Steve Dower added the comment: Instrumentation is not the same thing as profiling, and this one is certainly not intended for performance. That said, simply importing it shouldn't impact anyone else's performance either, and since six imports this, fixing it will have a pretty broad impact.

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

pmpp added the comment: > and potentially other platforms? strangely, it does not. but adding a blocking read on first requests may ruin profiling data on any platform. isn't http.server reserved for instrumentation and testing ? -- nosy: +pmpp

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

Change by Anirudha Bose : -- keywords: +patch pull_requests: +10273 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

Steve Dower added the comment: You're welcome to it - I deliberately left it for someone else to work on, though I'm happy to review and merge. The visible change of making this lazy is that if someone reads from the dict, it'll be missing system-specified content types (until we lazily

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

Danish Prakash added the comment: I would like to work on this if you have not already started, Steve. > We should check whether people read from > SimpleHTTPRequestHandler.extensions_map directly before calling guess_type(), > and decide how quickly we can make the change. Are you

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

New submission from Steve Dower : Importing http.server triggers mimetypes.init(), which can be fairly expensive on Windows (and potentially other platforms?) due to having to enumerate a lot of registry keys. Instead, SimpleHTTPRequestHandler.extensions_map can be a dict with just its