Re: "Design Decision Needed" is gone. Good riddance.

[Lennart Regebro]

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

[L Radhakrishna Rao]

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

[Val Neekman]

+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 

Re: Ticket 20147 - deprecate and replace request.META

[Luke Plant]

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.

[Russell Keith-Magee]

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

[Russell Keith-Magee]

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 

Re: "Design Decision Needed" is gone. Good riddance.

[Jeremy Dunck]

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

[Lennart Regebro]

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

[Luke Plant]

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

[Carl Meyer]

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 

Re: Ticket 20147 - deprecate and replace request.META

[Michael Manfre]

+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

[Angus Turner]

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

[Luke Plant]

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?

[Serge G. Spaolonzi]

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

[L Radhakrishna Rao]

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

[Horst Gutmann]

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

[L Radhakrishna Rao]

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.

[Jacob Kaplan-Moss]

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

[Aymeric Augustin]

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.

[Aymeric Augustin]

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.

[VernonCole]

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

[VernonCole]

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.