On 09/04/13 12:34, Tom Evans wrote: > The basis of web development was CGI. From CGI came everything. > Therefore, almost all webservers - Apache, nginx - almost all > frameworks - RoR, PHP, Django - that deal with the web will have > similar or equivalent environment hashes like this. > The convention for headers (uppercase header name, s/-/_/g, prepend > 'HTTP_') is similarly ubiquitous. > > Your argument is that this structure is confusing to the absolute > newbie who has never programmed a web application in his life. My > counter argument is that changing it would be confusing to anyone who > has ever programmed a web application in the last 20 years.
Well, that depends on which frameworks they use. From what I can tell, Java servlets have an API like request.getHeader("Accept-Language") without the HTTP_ name mangling, and ASP.NET has Request.Headers["Accept-Language"]. It's entirely possible to be a competent web developer without knowing about CGI name mangling. I don't often follow Java/C#, but I'll gladly follow anyone that is using a sensible API, and I really don't believe that current familiarity with quirky historical artefacts should hold us back - Python 3, to take one example, would never have happened with that attitude. I don't have (too much) of a problem with things like WSGI following CGI, if only because they had to in order to gain traction, but that isn't a reason why developers should be forced to do CGI name mangling to access a header. >> The biggest problem is what to do with our test Client and >> RequestFactory, which allow specifying headers as keyword arguments >> using the CGI style of naming e.g.: >> >> self.client.get('/path', HTTP_X_REQUESTED_WITH='XMLHttpRequest') >> >> Since keyword arguments can't have "-" in them, this is harder to >> replace. We could either leave it as it is, or add a new 'headers' >> keyword argument to these methods, deprecating **extra. > > This seems a problem with the API to Client and RequestFactory, not a > problem with request.META Now that we've dropped the proposal to deprecate request.META, and just add request.headers as an alternative for getting HTTP headers, these classes don't need to change. It was simply for consistency that I proposed fixing them. Regards, Luke -- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to firstname.lastname@example.org. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.