Re: "Design Decision Needed" is gone. Good riddance.
On Tue, Apr 9, 2013 at 12:02 AM, Jeremy Dunck wrote: > "easy" is for people new to contributing django or to open source in > general. Your view of "easy" may be different than our intended > meaning. :) Well, fair enough. :-) Maybe I can say it like this: I found that those with easy pickings were generally of the same class as those without. But I could be wrong of course. //Lennart -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.5 with Python 3.2
Hi Angus, Thanks for updating me on this. Regards Radhakrishna On Tue, Apr 9, 2013 at 1:33 AM, Angus Turner wrote: > Hi, > next time you're better off asking the question in django-users, as this > mailing list is for the development of Django itself! > > Thanks > Angus Turner > angusisf...@gmail.com > > > On Tue, Apr 9, 2013 at 1:49 AM, L Radhakrishna Rao < > satishsaga...@gmail.com> wrote: > >> Thanks Horst. >> >> Even I had referred that docs, and it stuck me. >> >> I just tried to simplify it. >> >> Regards >> >> -- >> 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 django-developers@googlegroups.com. >> Visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/chmYsKXaPl0/unsubscribe?hl=en > . > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Ticket 20147 - deprecate and replace request.META
+1 for leaving META alone. On Apr 8, 2013, at 7:45 PM, Russell Keith-Magee wrote: > > On Tue, Apr 9, 2013 at 5:13 AM, Carl Meyer wrote: >> Hi Luke, >> >> On 04/08/2013 02:02 PM, Luke Plant wrote: >> > This is already the subject of a ticket, but I didn't get a response >> > yet. Basically, the idea is replace things like: >> > >> > request.META['HTTP_ACCEPT'] >> > >> > with >> > >> > request.HEADERS['Accept'] >> > >> > request.META should be deprecated and replaced with request._META, >> > because it is just an implementation detail, and a really bizarre one at >> > that, full of cruft from a previous generation of web applications (CGI) >> > that should not be exposed in our API. >> >> I have no problem with providing a nicer API for getting at request >> headers that allows asking for un-mangled header names, but I don't >> think we should deprecate request.META (or turn it into a private >> implementation detail). >> >> Although the concept of a unified "request environ" that includes HTTP >> headers mashed together with various other environment and web server >> info may date back to CGI, it is not outdated; in fact it is a part of >> the WSGI specification too: >> http://www.python.org/dev/peps/pep-/#environ-variables >> >> I think the WSGI environ should always remain accessible through public >> API on a Django request object. >> >> > Anything else needed from META should also be replaced with a sensible API. >> >> I'm not sure how you envision this happening, since there is no fixed >> set of things that might be "needed from META" that we can provide >> purpose-specific API for. It is a legitimate use of WSGI for people to >> set arbitrary environ variables from their WSGI server and expect to be >> able to read those variables from Django, and they shouldn't have to use >> private API to do this. > > I agree with Carl. I like the idea of the new HEADERS that is simpler to > access, but I think removing/renaming META isn't desirable. > > HEADERS will be introducing a layer of smarts, and as helpful as those smarts > will be under 95% of circumstances, I'd be willing to bet that *someone* has > a use case for getting at the raw headers. > > On top of that, there's plenty of code out there that is currently using META > without any problems -- the issue is with new users understanding which META > key to use, not with the key working correctly once it's been discovered. > We're not closing a security hole, or making new functionality possible -- > we're just making some code a little easier to read. Forcing all that code to > be updated to use HEADERS strikes me as code churn. > > I'd much rather see META continue as a publicly available, but generally > discouraged API, rather than formally deprecating it. > >> > This might seem to be a big change simply for the sake of a clean API, >> > but I'm more and more motivated by these thoughts: >> > >> > * Web development is hard enough as it is. "Explain this to a newbie >> > without getting embarrassed" is a good test. >> >> Sure; if we introduce a new API for getting at HTTP headers sans >> name-mangling, I think it'd be fine to consider request.META "advanced >> API" and adjust the documentation accordingly to make it much less >> prominent. >> >> > There is also the advantage of a *much* cleaner repr(request), >> > especially in a development environment, because you don't have all the >> > other junk from os.environ. >> >> If we are trying to make repr(request) really be a full reproduction of >> all relevant request data (such that the request instance could be fully >> reconstructed from it) then I don't think this goal is achievable; it is >> not an option (IMO) to remove WSGI environ data from the request >> entirely, because this would make data that is part of the WSGI spec >> inaccessible to Django users. >> >> (I haven't checked whether the current repr(request) meets the >> full-reconstruction criteria; if it already doesn't then I don't really >> care what we show in it, we could trim it down further with or without >> your proposed change.) >> >> > 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. >> >> Similar to above, I think we could add a new "headers" arg for >> friendlier specification of HTTP headers, but I don't think we should >> deprecate **extra. (This of course would mean we have to decide and >> document which takes precedence if they conflict.) >> >> > The silliness has infected other places, like SECURE_PROXY_SSL_HEADER >> > which follows the same CGI convention (and in each c
Re: Ticket 20147 - deprecate and replace request.META
On 08/04/13 22:13, Carl Meyer wrote: > Although the concept of a unified "request environ" that includes HTTP > headers mashed together with various other environment and web server > info may date back to CGI, it is not outdated; in fact it is a part of > the WSGI specification too: > http://www.python.org/dev/peps/pep-/#environ-variables I realise it is part of the WSGI spec, but encoding the CGI peculiarities into a more modern spec seems pretty misguided to me - you have to create a WSGI-CGI gateway to run CGI programs anyway, and you could put the backwards compatibility mapping there, instead of in the WSGI spec. I actually wish that WSGI didn't do any HTTP parsing at all. >> There is also the advantage of a *much* cleaner repr(request), >> especially in a development environment, because you don't have all the >> other junk from os.environ. > > If we are trying to make repr(request) really be a full reproduction of > all relevant request data (such that the request instance could be fully > reconstructed from it) then I don't think this goal is achievable; it is > not an option (IMO) to remove WSGI environ data from the request > entirely, because this would make data that is part of the WSGI spec > inaccessible to Django users. > > (I haven't checked whether the current repr(request) meets the > full-reconstruction criteria; if it already doesn't then I don't really > care what we show in it, we could trim it down further with or without > your proposed change.) You can't currently reproduce the request this way - the stream for the request body contents comes out as something opaque. You're right we could trim the repr with or without my change - it would simply have made the set of things to display more obvious. We should probably consider the places where repr(request) is used. It's probably just in logging systems. However, Sentry is one of the most popular and it does it's own representation of the request object, it seems, so if we left META alone it wouldn't be affected. It seems to me that repr(request) is most useful for development-environment debugging, and currently could be improved a lot for that use case. >> Is anyone strongly opposed to this? If not, in Aymeric's spirit of >> decisiveness, I'll push it forward. > > I'm fine with new request.headers API; I'm opposed to deprecation of > request.META. I would be fine with your modification of my proposal, not least because it would be a *lot* less work! The only disadvantage is "two ways to do it". If you want to grep for a particular header, you've got 2 things to grep for now. However, that problem already existed due to META - you've got things like QUERY_STRING and request.GET, HTTP_HOST and request.get_host(), X_REQUESTED_WITH and request.is_ajax(). 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: "Design Decision Needed" is gone. Good riddance.
On Tue, Apr 9, 2013 at 6:11 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 8 avr. 2013, at 23:58, Lennart Regebro wrote: > > > On Mon, Apr 8, 2013 at 4:57 PM, Jacob Kaplan-Moss > wrote: > >> Thanks, please let me know if you have questions! > > > > Nope, but a suggestion: Mark new tickets as "easy pickings" by > > default. During the sprint I didn't find any ticket that wasn't either > > more than a year old (often indeed flagged as DDN) or easy. :-) > > I agree that the "Easy pickings" flag doesn't work so well. When > an easy ticket that stays open for more than a few weeks, it isn't > actually easy. > True - but for those couple of weeks, it's a very useful marker for contributors looking for something that has been pre qualified as being simple to work on. That's a useful distinction to make, because it separates those tickets from the hundreds of candidates. Yours, Russ Magee %-) -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Ticket 20147 - deprecate and replace request.META
On Tue, Apr 9, 2013 at 5:13 AM, Carl Meyer wrote: > Hi Luke, > > On 04/08/2013 02:02 PM, Luke Plant wrote: > > This is already the subject of a ticket, but I didn't get a response > > yet. Basically, the idea is replace things like: > > > > request.META['HTTP_ACCEPT'] > > > > with > > > > request.HEADERS['Accept'] > > > > request.META should be deprecated and replaced with request._META, > > because it is just an implementation detail, and a really bizarre one at > > that, full of cruft from a previous generation of web applications (CGI) > > that should not be exposed in our API. > > I have no problem with providing a nicer API for getting at request > headers that allows asking for un-mangled header names, but I don't > think we should deprecate request.META (or turn it into a private > implementation detail). > > Although the concept of a unified "request environ" that includes HTTP > headers mashed together with various other environment and web server > info may date back to CGI, it is not outdated; in fact it is a part of > the WSGI specification too: > http://www.python.org/dev/peps/pep-/#environ-variables > > I think the WSGI environ should always remain accessible through public > API on a Django request object. > > > Anything else needed from META should also be replaced with a sensible > API. > > I'm not sure how you envision this happening, since there is no fixed > set of things that might be "needed from META" that we can provide > purpose-specific API for. It is a legitimate use of WSGI for people to > set arbitrary environ variables from their WSGI server and expect to be > able to read those variables from Django, and they shouldn't have to use > private API to do this. I agree with Carl. I like the idea of the new HEADERS that is simpler to access, but I think removing/renaming META isn't desirable. HEADERS will be introducing a layer of smarts, and as helpful as those smarts will be under 95% of circumstances, I'd be willing to bet that *someone* has a use case for getting at the raw headers. On top of that, there's plenty of code out there that is currently using META without any problems -- the issue is with new users understanding which META key to use, not with the key working correctly once it's been discovered. We're not closing a security hole, or making new functionality possible -- we're just making some code a little easier to read. Forcing all that code to be updated to use HEADERS strikes me as code churn. I'd much rather see META continue as a publicly available, but generally discouraged API, rather than formally deprecating it. > This might seem to be a big change simply for the sake of a clean API, > > but I'm more and more motivated by these thoughts: > > > > * Web development is hard enough as it is. "Explain this to a newbie > > without getting embarrassed" is a good test. > > Sure; if we introduce a new API for getting at HTTP headers sans > name-mangling, I think it'd be fine to consider request.META "advanced > API" and adjust the documentation accordingly to make it much less > prominent. > > > There is also the advantage of a *much* cleaner repr(request), > > especially in a development environment, because you don't have all the > > other junk from os.environ. > > If we are trying to make repr(request) really be a full reproduction of > all relevant request data (such that the request instance could be fully > reconstructed from it) then I don't think this goal is achievable; it is > not an option (IMO) to remove WSGI environ data from the request > entirely, because this would make data that is part of the WSGI spec > inaccessible to Django users. > > (I haven't checked whether the current repr(request) meets the > full-reconstruction criteria; if it already doesn't then I don't really > care what we show in it, we could trim it down further with or without > your proposed change.) > > > 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. > > Similar to above, I think we could add a new "headers" arg for > friendlier specification of HTTP headers, but I don't think we should > deprecate **extra. (This of course would mean we have to decide and > document which takes precedence if they conflict.) > > > The silliness has infected other places, like SECURE_PROXY_SSL_HEADER > > which follows the same CGI convention (and in each case the docs have to > > note how to do it correctly!). In this case we can detect people using > > the old style 'HTTP_' and raise a deprecation warning, and allow the > > sensible way. > > There might be cases where people are using
Re: "Design Decision Needed" is gone. Good riddance.
On 8 avr. 2013, at 23:58, Lennart Regebro wrote: > On Mon, Apr 8, 2013 at 4:57 PM, Jacob Kaplan-Moss wrote: >> Thanks, please let me know if you have questions! > > Nope, but a suggestion: Mark new tickets as "easy pickings" by > default. During the sprint I didn't find any ticket that wasn't either > more than a year old (often indeed flagged as DDN) or easy. :-) I agree that the "Easy pickings" flag doesn't work so well. When an easy ticket that stays open for more than a few weeks, it isn't actually easy. At sprints, I often suggest to browse Trac by component. With the exception of the ORM and the admin, such queries return a manageable and consistent set of tickets, making it easier to locate something to work on. -- Aymeric. -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: "Design Decision Needed" is gone. Good riddance.
"easy" is for people new to contributing django or to open source in general. Your view of "easy" may be different than our intended meaning. :) On Mon, Apr 8, 2013 at 2:58 PM, Lennart Regebro wrote: > On Mon, Apr 8, 2013 at 4:57 PM, Jacob Kaplan-Moss wrote: >> Thanks, please let me know if you have questions! > > Nope, but a suggestion: Mark new tickets as "easy pickings" by > default. During the sprint I didn't find any ticket that wasn't either > more than a year old (often indeed flagged as DDN) or easy. :-) > > //Lennart > > -- > 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 django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: "Design Decision Needed" is gone. Good riddance.
On Mon, Apr 8, 2013 at 4:57 PM, Jacob Kaplan-Moss wrote: > Thanks, please let me know if you have questions! Nope, but a suggestion: Mark new tickets as "easy pickings" by default. During the sprint I didn't find any ticket that wasn't either more than a year old (often indeed flagged as DDN) or easy. :-) //Lennart -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Ticket 20147 - deprecate and replace request.META
On 08/04/13 21:17, Michael Manfre wrote: > +1 to a saner repr(request) and not having to type "HTTP_". What sort of > deprecation cycle are you thinking for this? I'm thinking the normal cycle: 1.6 - request.HEADERS added, probably a few friends too. - request._META added - accessing request.META gives PendingDeprecationWarning 1.7 - request.META gives DeprecationWarning 1.8 - request.META is removed. If we find that there are some other attributes/method that need to be added to HttpRequest in Django 1.7, and direct access to request._META was still necessary, then we could extend the deprecation cycle - 1.7 would give PendingDeprecationWarning. Regards, Luke -- Be careful of reading health books, you might die of a misprint. -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Ticket 20147 - deprecate and replace request.META
Hi Luke, On 04/08/2013 02:02 PM, Luke Plant wrote: > This is already the subject of a ticket, but I didn't get a response > yet. Basically, the idea is replace things like: > > request.META['HTTP_ACCEPT'] > > with > > request.HEADERS['Accept'] > > request.META should be deprecated and replaced with request._META, > because it is just an implementation detail, and a really bizarre one at > that, full of cruft from a previous generation of web applications (CGI) > that should not be exposed in our API. I have no problem with providing a nicer API for getting at request headers that allows asking for un-mangled header names, but I don't think we should deprecate request.META (or turn it into a private implementation detail). Although the concept of a unified "request environ" that includes HTTP headers mashed together with various other environment and web server info may date back to CGI, it is not outdated; in fact it is a part of the WSGI specification too: http://www.python.org/dev/peps/pep-/#environ-variables I think the WSGI environ should always remain accessible through public API on a Django request object. > Anything else needed from META should also be replaced with a sensible API. I'm not sure how you envision this happening, since there is no fixed set of things that might be "needed from META" that we can provide purpose-specific API for. It is a legitimate use of WSGI for people to set arbitrary environ variables from their WSGI server and expect to be able to read those variables from Django, and they shouldn't have to use private API to do this. > This might seem to be a big change simply for the sake of a clean API, > but I'm more and more motivated by these thoughts: > > * Web development is hard enough as it is. "Explain this to a newbie > without getting embarrassed" is a good test. Sure; if we introduce a new API for getting at HTTP headers sans name-mangling, I think it'd be fine to consider request.META "advanced API" and adjust the documentation accordingly to make it much less prominent. > There is also the advantage of a *much* cleaner repr(request), > especially in a development environment, because you don't have all the > other junk from os.environ. If we are trying to make repr(request) really be a full reproduction of all relevant request data (such that the request instance could be fully reconstructed from it) then I don't think this goal is achievable; it is not an option (IMO) to remove WSGI environ data from the request entirely, because this would make data that is part of the WSGI spec inaccessible to Django users. (I haven't checked whether the current repr(request) meets the full-reconstruction criteria; if it already doesn't then I don't really care what we show in it, we could trim it down further with or without your proposed change.) > 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. Similar to above, I think we could add a new "headers" arg for friendlier specification of HTTP headers, but I don't think we should deprecate **extra. (This of course would mean we have to decide and document which takes precedence if they conflict.) > The silliness has infected other places, like SECURE_PROXY_SSL_HEADER > which follows the same CGI convention (and in each case the docs have to > note how to do it correctly!). In this case we can detect people using > the old style 'HTTP_' and raise a deprecation warning, and allow the > sensible way. There might be cases where people are using an environ var rather than an HTTP header to indicate proxied SSL, and currently SECURE_PROXY_SSL_HEADER works fine this way (despite the HEADER in the name). That said, I can't immediately find any current prominent documents recommending this or situations where using a HTTP header instead wouldn't be workable. Unless someone comes up with such a situation, and given that both the name of the setting and its documentation only discuss its use with headers, I think I'd be ok deprecating its use with non-headers and moving to friendlier header names. > We would probably also need to add a few methods/attributes to > HttpRequest to proxy the few things you need from request.META that are > not headers, like REMOTE_ADDRESS and REMOTE_USER As I mentioned above, I don't think we can dictate the "few things you need from request.META" and make the rest inaccessible. > Is anyone strongly opposed to this? If not, in Aymeric's spirit of > decisiveness, I'll push it forward. I'm fine with new request.headers API; I'm opposed to deprecation of request.META. Carl -- You received this messag
Re: Ticket 20147 - deprecate and replace request.META
+1 to a saner repr(request) and not having to type "HTTP_". What sort of deprecation cycle are you thinking for this? Regards, Michael Manfre On Mon, Apr 8, 2013 at 4:02 PM, Luke Plant wrote: > Hi all, > > This is already the subject of a ticket, but I didn't get a response > yet. Basically, the idea is replace things like: > > request.META['HTTP_ACCEPT'] > > with > > request.HEADERS['Accept'] > > request.META should be deprecated and replaced with request._META, > because it is just an implementation detail, and a really bizarre one at > that, full of cruft from a previous generation of web applications (CGI) > that should not be exposed in our API. > > Anything else needed from META should also be replaced with a sensible API. > > This might seem to be a big change simply for the sake of a clean API, > but I'm more and more motivated by these thoughts: > > * Web development is hard enough as it is. "Explain this to a newbie > without getting embarrassed" is a good test. > > * A general philosophy of pro-actively keeping things clean and sensible > is necessary to avoid being overrun with madness long term. > > There is also the advantage of a *much* cleaner repr(request), > especially in a development environment, because you don't have all the > other junk from os.environ. > > 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. > > The silliness has infected other places, like SECURE_PROXY_SSL_HEADER > which follows the same CGI convention (and in each case the docs have to > note how to do it correctly!). In this case we can detect people using > the old style 'HTTP_' and raise a deprecation warning, and allow the > sensible way. > > We would probably also need to add a few methods/attributes to > HttpRequest to proxy the few things you need from request.META that are > not headers, like REMOTE_ADDRESS and REMOTE_USER > > Is anyone strongly opposed to this? If not, in Aymeric's spirit of > decisiveness, I'll push it forward. > > https://code.djangoproject.com/ticket/20147 > > Regards, > > Luke > > > -- > Be careful of reading health books, you might die of a misprint. > -- 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 django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.5 with Python 3.2
Hi, next time you're better off asking the question in django-users, as this mailing list is for the development of Django itself! Thanks Angus Turner angusisf...@gmail.com On Tue, Apr 9, 2013 at 1:49 AM, L Radhakrishna Rao wrote: > Thanks Horst. > > Even I had referred that docs, and it stuck me. > > I just tried to simplify it. > > Regards > > -- > 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 django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Ticket 20147 - deprecate and replace request.META
Hi all, This is already the subject of a ticket, but I didn't get a response yet. Basically, the idea is replace things like: request.META['HTTP_ACCEPT'] with request.HEADERS['Accept'] request.META should be deprecated and replaced with request._META, because it is just an implementation detail, and a really bizarre one at that, full of cruft from a previous generation of web applications (CGI) that should not be exposed in our API. Anything else needed from META should also be replaced with a sensible API. This might seem to be a big change simply for the sake of a clean API, but I'm more and more motivated by these thoughts: * Web development is hard enough as it is. "Explain this to a newbie without getting embarrassed" is a good test. * A general philosophy of pro-actively keeping things clean and sensible is necessary to avoid being overrun with madness long term. There is also the advantage of a *much* cleaner repr(request), especially in a development environment, because you don't have all the other junk from os.environ. 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. The silliness has infected other places, like SECURE_PROXY_SSL_HEADER which follows the same CGI convention (and in each case the docs have to note how to do it correctly!). In this case we can detect people using the old style 'HTTP_' and raise a deprecation warning, and allow the sensible way. We would probably also need to add a few methods/attributes to HttpRequest to proxy the few things you need from request.META that are not headers, like REMOTE_ADDRESS and REMOTE_USER Is anyone strongly opposed to this? If not, in Aymeric's spirit of decisiveness, I'll push it forward. https://code.djangoproject.com/ticket/20147 Regards, Luke -- Be careful of reading health books, you might die of a misprint. -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Kickstarter for Django Admin?
It looks good, Thanks for sharing. On Wed, Apr 3, 2013 at 8:41 PM, Jason Kraus wrote: > > A RESTful api with a separate template client is exactly what hyperadmin > aims to do: https://github.com/zbyte64/django-hyperadmin > I've played around with bolting on an emberjs client or having an admin > powered by django templates and both options can and do work. It pretty much > works as you describe, a CRUD engine operates independently of the > presentation layer but for this to work reasonably links themselves must be > communicated so that filtering, sorting, etc can easily be represented by a > variety of clients. If you don't like the client you can choose or build > another one without having to re-implement the admin operations and logic. > > The focus on HATEOAS also allows for No-SQL storages > (https://github.com/zbyte64/django-hyperadmin-dockitresource) to be used by > the same clients because the functionality emitted by the document store is > described as links. If you want more functionality exposed then it is a > matter of getting your resource to emit the proper links. > -- Serge G. Spaolonzi Cobalys Systems http://www.cobalys.com -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.5 with Python 3.2
Thanks Horst. Even I had referred that docs, and it stuck me. I just tried to simplify it. Regards -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.5 with Python 3.2
This is documented here: https://docs.djangoproject.com/en/dev/topics/python3/#str-and-unicode-methods:-) Cheers, Horst On Mon, Apr 8, 2013 at 4:42 PM, L Radhakrishna Rao wrote: > I was following tutorials of django book, where python 2.7 version is used. > > I am using python 3.2 version and django 1.5. > > The django book chapter 5 'Adding Model String Represenations' needs to be > changed while publishing book for python 3.x version. > > The 'def__unicode__(self)' does not work if Python3.x version is used. > > When I implemented the same code with 'def __str__(self):', the model > string got retrieved. > > If the change is done, please discard my thread. > > Thanks > > -- > 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 django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Django 1.5 with Python 3.2
I was following tutorials of django book, where python 2.7 version is used. I am using python 3.2 version and django 1.5. The django book chapter 5 'Adding Model String Represenations' needs to be changed while publishing book for python 3.x version. The 'def__unicode__(self)' does not work if Python3.x version is used. When I implemented the same code with 'def __str__(self):', the model string got retrieved. If the change is done, please discard my thread. Thanks -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
"Design Decision Needed" is gone. Good riddance.
Hi folks -- "Design decision needed" is where good tickets go to die. The idea was that someone could come by later and make the decision, but as it turns out, Someone doesn't work here. In practice, DDN tickets sat open, often for years, and just frustrated everyone. So we're getting rid of DDN; we (mostly Aymeric, thanks!) closed out all of 'em over the last few weeks, and we're removing the status today. We're working on updating the contributing docs to reflect this change. If you're working on triage, this means that instead of marking a ticket DDN you should do one of the following: - Just make the decision yourself. If you're 75% sure that a ticket is legit, just mark it "accepted" and move on. Likewise, if you're 80% sure a ticket is invalid, mark it so. Remember that nothing's set in stone; it's perfectly OK to be wrong. When I talk to people in the community, most of them tell me that what frustrates them about the ticket process is inaction. They'd rather have a ticket marked "wontfix" quickly than have it sit in an indeterminate state for months or years. - Find someone else (in #django-dev on IRC is a good bet) who can help you make a call. - For "big" features, or tickets that're otherwise hard to act on, move them to the mailing list for discussion. There's a class of tickets -- feature additions, usually -- that don't do well on the ticket tracker. In these cases we need a concrete proposal and/or patches to be able to make a call correctly, so the right place to hash that stuff out is here, not in Trac. In these cases, we'll usually close the ticket until a real concrete proposal emerges. Thanks, please let me know if you have questions! Jacob -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Extending the DATABASES = {'xx': {'NAME': construct to carry additional information and / or virtual names
On 8 avr. 2013, at 10:21, VernonCole wrote: > 1) re-implement the argument signature of adodbapi so that it agrees with the > recommendation for positional and keyword arguments in PEP 249, except that > the first positional argument is called "connection_string" rather than > "dsn". ((Also handle the case where "dsn" is defined but "connection_string" > is not by using "dsn" as a default.)) The user may supply other keyword > arguments not documented in PEP 249 -- for example "timeout". > > 2) permit the first positional argument to be a dictionary, which will be > merged with **kwargs. This will make it easy to pass both the DATABASES > dictionary and other keyword arguments in. > > 3) Look in the resulting merged dictionary for key "OPTIONS". If present, > merge that dictionary into the existing keywords. > > 4) Django specifies that database connection keywords are UPPER CASE. Pep > 249 specifies the same tokens in lower case. Therefore, go through the > dictionary, > creating lower case copies of any upper case keyword items (if they are not > already defined.) In my opinion, adodbapi should have an API that makes sense by itself, regardless of Django. Then the `get_connection_params` method of the database backend should take care of mangling arguments to match that API. Of course, that's bikeshedding: you write the software, you get to chose the API that suits your tastes. > 4) Create an adodbapi.remote module with the same signatures as adodbapi. > > 5) In the remote, use the dictionary keywords "'pyro_connection", > "remote_proxy" and "remote_port" to connect to the server, supplying > appropriate defaults. > > 6) Create adodbapi.server.py which will be a PyRO server daemon for adodbapi > connections. > > 7) The remote client passes the entire connection keyword dictionary to the > server. The remote or the server may add keywords and supply defaults. > > 8) The server will attempt an adodbapi.connect(*args, **kwargs) using the > merged keyword dictionary. > > 9) Internally, adodbapi.connect will execute the equivalent of: > connection_string = kwargs['connection_string'] % kwargs > to allow the programmer to build her connection string by using Python > "String Formatting Operations". She will place "%(keyword)s" constructs in > her connection > string where appropriate. > > 10) Dictionary keywords will be used for ADO option settings: > ADO.Connection_timout = kwargs.get('timeout', 30) Yes, overall, that design sounds reasonable. It's similar to running PostgreSQL behind pg_pool (a connection pooler). As long as Django connects to something that behaves like a database, it's all right. >From the point of view of Django, your PyRO server daemon will be the >database, even though it's actually a proxy. Whether the proxy gets its >parameters from its own configuration or from Django doesn't really matter. >Just go for the most practical solution for your use case. -- Aymeric. -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: currency of DATABASES = {'xx' : {'OPTIONS' = {'AUTOCOMMIT' ... flag.
On 8 avr. 2013, at 10:33, VernonCole wrote: > I am confused by the documentation. I cannot seem to figure out whether the > AUTOCOMMIT switch is a new feature on the way in, or an obsolete feature on > the road to deprecation. Defining AUTOCOMMIT = True within OPTIONS, as shown in the subject of this message, was a PostgreSQL-specific feature that will be removed (well, ignored) in 1.6. Defining AUTOCOMMIT = False next to ENGINE and OPTIONS is new in 1.6. It's a per-database replacement for the even-more-confusing setting called TRANSACTIONS_MANAGED. You should never use it anyway! Django 1.5 uses the behavior mandated by PEP 249 ie. no autocommit (unless you're using PostgreSQL and you set the AUTOCOMMIT option). Django 1.6 will use autocommit on all databases. You'll find more information in my posts to this list, one or two months ago. -- Aymeric. -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
currency of DATABASES = {'xx' : {'OPTIONS' = {'AUTOCOMMIT' ... flag.
I am confused by the documentation. I cannot seem to figure out whether the AUTOCOMMIT switch is a new feature on the way in, or an obsolete feature on the road to deprecation. I can easily add the feature to adodbapi, but should I do so or not? -- Vernon -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Extending the DATABASES = {'xx': {'NAME': construct to carry additional information and / or virtual names
Thanks for the feedback. I have incorporated your suggestions into my design. There is nobody around here I can use for a design review, so, begging your forgiveness, I will have to do it here. Here is how I am setting up the prototype... 1) re-implement the argument signature of adodbapi so that it agrees with the recommendation for positional and keyword arguments in PEP 249, except that the first positional argument is called "connection_string" rather than "dsn". ((Also handle the case where "dsn" is defined but "connection_string" is not by using "dsn" as a default.)) The user may supply other keyword arguments not documented in PEP 249 -- for example "timeout". 2) permit the first positional argument to be a dictionary, which will be merged with **kwargs. This will make it easy to pass both the DATABASES dictionary and other keyword arguments in. 3) Look in the resulting merged dictionary for key "OPTIONS". If present, merge that dictionary into the existing keywords. 4) Django specifies that database connection keywords are UPPER CASE. Pep 249 specifies the same tokens in lower case. Therefore, go through the dictionary, creating lower case copies of any upper case keyword items (if they are not already defined.) 4) Create an adodbapi.remote module with the same signatures as adodbapi. 5) In the remote, use the dictionary keywords "'pyro_connection", "remote_proxy" and "remote_port" to connect to the server, supplying appropriate defaults. 6) Create adodbapi.server.py which will be a PyRO server daemon for adodbapi connections. 7) The remote client passes the entire connection keyword dictionary to the server. The remote or the server may add keywords and supply defaults. 8) The server will attempt an adodbapi.connect(*args, **kwargs) using the merged keyword dictionary. 9) Internally, adodbapi.connect will execute the equivalent of: connection_string = kwargs['connection_string'] % kwargs to allow the programmer to build her connection string by using Python "String Formatting Operations". She will place "%(keyword)s" constructs in her connection string where appropriate. 10) Dictionary keywords will be used for ADO option settings: ADO.Connection_timout = kwargs.get('timeout', 30) --- How does that sound? -- Vernon -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.