[issue26380] Add an http method enum

[Ethan Furman]

Ethan Furman added the comment:

That was the last nudge I needed.

Thanks, everyone.

--
assignee:  -> ethan.furman
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26380] Add an http method enum

[Raymond Hettinger]

Raymond Hettinger added the comment:

I concur that the enum adding nothing of value here.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26380] Add an http method enum

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

what's the status of your issue ?

--
nosy: +matrixise

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26380] Add an http method enum

[Martin Panter]

Martin Panter added the comment:

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".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26380] Add an http method enum

[Terry J. Reedy]

Terry J. Reedy added the comment:

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

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26380] Add an http method enum

[Demian Brecht]

Demian Brecht added the comment:

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

--
Added file: http://bugs.python.org/file41962/issue26380_2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26380] Add an http method enum

[Demian Brecht]

Demian Brecht added the 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26380] Add an http method enum

[Martin Panter]

Martin Panter added the 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. 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.

--
nosy: +martin.panter
stage:  -> patch review
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26380] Add an http method enum

[Demian Brecht]

Demian Brecht added the comment:

> 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.

--
Added file: http://bugs.python.org/file41960/issue26380_1.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26380] Add an http method enum

[Ethan Furman]

Ethan Furman added the comment:

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

--
nosy: +ethan.furman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26380] Add an http method enum

[Demian Brecht]

Demian Brecht added the comment:

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

--
keywords: +patch
Added file: http://bugs.python.org/file41947/issue26380.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26380] Add an http method enum

[Demian Brecht]

New submission from Demian Brecht:

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?

--
components: Library (Lib)
keywords: needs review
messages: 260431
nosy: demian.brecht, r.david.murray
priority: normal
severity: normal
status: open
title: Add an http method enum
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com