[PATCH 07 of 10] py3: add compatibilty functions for urllib2.Request.get_{type|host|selector}()

Yuya Nishihara yuya at tcha.org
Tue May 9 10:50:05 EDT 2017


On Sat, 6 May 2017 08:38:37 +0530, Pulkit Goyal wrote:
> >
> > +    def request_type(request):
> > +        '''returns the scheme of urllib.request.Request class object'''
> > +        return request.type
> > +
> > +    def request_host(request):
> > +        '''returns the host of urllib.request.Request class object'''
> > +        return request.host
> > +
> > +    def request_selector(request):
> > +        '''return the URI path of a urllib.request.Request class object'''
> > +        return request.selector
> > +
> >
> > ​For reviewers, these functions here break test-check-commit.t as it
> introduces foo_bar naming functions. I grepped and looked for a commit
> message explaining the reason why they are not allowed and can't find one.
> Also as its visible, naming foo_bar will be the best here, otherwise we
> might end up function names which are hard to parse.
> I pushed this commit ​because I felt this convention should be used.

"for consistency and ease of reference."

https://www.mercurial-scm.org/wiki/CodingStyle#Naming_conventions

Can't we extend the Request class instead of wrapping functions?


More information about the Mercurial-devel mailing list