Super minor annoyance that I've had over multiple projects is seeing either hard coded strings being used (which is a bit of a no-no in terms of best practices) or each project defining its own set of constants for http methods. Why not just include a standard set in http as is done for status codes?

If nobody's opposed to the addition, I'll run through the unit tests and replace the hard coded strings.

I don't have a firm opinion at this point -- can you give a few examples of how this will help in code?

> I don't have a firm opinion at this point -- can you give a few examples of how this will help in code?

It'll help solely with consistency across projects. Generally, using constants are generally favored over using hardcoded values. Mainly, it helps reduce typos. Some projects use literals, others use project-specific constants. It's something that I've found myself redefining over various projects, and I just though "why couldn't this be added to the standard library, given it's an attribute of the HTTP/1.1 RFC"?

/Very/ minor, personal annoyance.

The updated patch fixes the OPTION typo.

I can see the advantage of using an enum over a plain string. But you only get an error at run time, not compile time, if you misspell it. And there is also the disadvantage of the extra boilerplate of importing HTTPMessage. So I don’t have a strong opinion either way. Do other libraries have a similar enum?

BTW I think it is actually OPTIONS; see review comment.

> I can see the advantage of using an enum over a plain string. But you only get an error at run time, not compile time, if you misspell it.

Sure, but at least you're giving static analysis utilities the chance to catch it up front.

> And there is also the disadvantage of the extra boilerplate of importing HTTPMessage.

I guess that all depends on how you're importing your modules. If you just import "http", then there's no additional boilerplate.

> So I don’t have a strong opinion either way. Do other libraries have a similar enum?

I haven't seen enums in other libraries, only constants. I figured that it might as well be consistent with HTTPStatus, although granted, HTTPStatus does a little more than the methods.

> BTW I think it is actually OPTIONS; see review comment.
Well, don't I feel silly. Fixed.

If I were deciding, I would be inclined to reject this.  Part of the understanding when enums were added was that they would not automatically be used in the stdlib anywhere there could be used.

To answer 'why not', there is an obvious gain to naming arbitrary numerical code, as with HTTPStatus.xyz.  I do not see any gain from replacing 'GET'*  with HTTPMethod.GET.  Just more work to write and read.

*Does http require uppercase for the methods?

To answer 'best practice',  I disagree with the premise that 'hardcoding' such short meaningful names is bad.  I think that this is a mis-application of a sometimes valid principle.

If people who do like such replacements are changing spellings, other than to lower case the words (enum value do not have to be uppercase), in the process, shame on them. Otherwise, typing HTTPMethod.OPTIONS is harde to type correctly, not easier, than 'OPTIONS'.  If you posted evidence as to your claim, I might be more favorably inclined.  On the other hand, if everyone used the quoted strings, 'GET', etc, there would be no problem with inconsistency.

My personal experience with turning constant strings into constant names is with tkinter, which has about 50 assignments like "E = 'e'", "RAISED = 'raised'", and so on.  I consider them more a nuisance than a help.  CAPS are harder to type than letters, and they give TOO MUCH EMPHASIS to rather minor configuration issues.  If one does 'import tkinter' or 'import tkinter as tk' instead of 'from tkinter import *', then "relief=tk.RAISED" is definitely harder to write as "relieve='raised'", and to me uglier.

To me, your later throw-in comment about static analyzers might be the most persuasive point you made

The RFC for HTTP says the method is case-sensitive, although I have seen one person use lowercase (probably by accident). So “over the wire” it has to be uppercase b"GET".

> To me, your later throw-in comment about static analyzers might be the most persuasive point you made

Well, we're in agreement there :) As I'd mentioned, at best it's a minor annoyance. I'm entirely on the fence about the use of the enum as well and after reading your response, am more inclined to change this to simple constants as the enum really doesn't add much.

what's the status of your issue ?

I concur that the enum adding nothing of value here.

That was the last nudge I needed.

Thanks, everyone.