[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