Re: Last call: #11863 (Model.objects.raw)

2009-12-15 Thread Sean O'Connor
Big thanks Jacob for picking up my slack and putting the finishing touches on the patch and writing the docs. Work got crazy and I dropped the ball. Definitely happy that the work will get completed and put into trunk regardless. In regard to the deferred fields option, I'll let Jacob speak for

Re: Python version roadmap

2009-12-15 Thread Russell Keith-Magee
On Wed, Dec 16, 2009 at 11:23 AM, James Bennett wrote: > On Tue, Dec 15, 2009 at 9:15 PM, DULMANDAKH Sukhbaatar > wrote: >> Please note that python 2.4 is default in RHEL5. > > I'm aware of that, and concerns about RHEL were noted when I > originally

Re: Re: Python version roadmap

2009-12-15 Thread s . kuzmenko
A word of caution on dropping support of python 2.4: it is still shipped with RHEL 5 which is supported until 2014 (http://www.redhat.com/security/updates/errata/). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group,

Re: Python version roadmap

2009-12-15 Thread James Bennett
On Tue, Dec 15, 2009 at 9:15 PM, DULMANDAKH Sukhbaatar wrote: > Please note that python 2.4 is default in RHEL5. I'm aware of that, and concerns about RHEL were noted when I originally proposed the roadmap. But that's Red Hat's problem; if they want to keep shipping ancient

Re: Python version roadmap

2009-12-15 Thread Alex Gaynor
On Tue, Dec 15, 2009 at 10:15 PM, DULMANDAKH Sukhbaatar wrote: >> Also, we should be adding any plans to drop 2.4, 2.5 etc into the >> internals/deprecation.txt documentation, and we ought to do that >> *before* 1.2 is released, to give as much warning as possible. > >

Re: Python version roadmap

2009-12-15 Thread DULMANDAKH Sukhbaatar
> Also, we should be adding any plans to drop 2.4, 2.5 etc into the > internals/deprecation.txt documentation, and we ought to do that > *before* 1.2 is released, to give as much warning as possible. Please note that python 2.4 is default in RHEL5. -- Regards Dulmandakh

Re: Re: why last_login in django.contrib.auth.models.User cannot be null?

2009-12-15 Thread s . kuzmenko
> However, the bigger issue is that I think changing the definition of > this field really requires a migration mechanism (which would update > existing databases), which we don't have. We really don't want the > situation of bugs which are impossible to reproduce because they > depend on

Re: Last call: #11863 (Model.objects.raw)

2009-12-15 Thread Russell Keith-Magee
On Wed, Dec 16, 2009 at 6:15 AM, Jacob Kaplan-Moss wrote: > Hey folks -- > > Forgot to mention it during the sprint this weekend, but I've pushed a > RC patch to #11863, Model.objects.raw(). If anyone's got any feedback, > let it fly. Otherwise, I'll be checking this in in a

Re: CRLF vs just LF in multipart parser

2009-12-15 Thread Karen Tracey
On Tue, Dec 15, 2009 at 7:33 PM, Dave Peck wrote: > Hello, > > I notice that Django's multipart form parser expects CRLF-style line > endings. Specifically, > django.http.multipartparser::parse_boudary_stream has a hardcoded > expectation of '\r\n\r\n' to end a part header. >

Re: Last call: #11863 (Model.objects.raw)

2009-12-15 Thread Jacob Kaplan-Moss
Thanks for the review, Jeremy. On Tue, Dec 15, 2009 at 5:31 PM, Jeremy Dunck wrote: > This bit doesn't seem to be true; It seems that missing fields will > raise InsuficientFields instead.  Am I reading it wrong? Ah, good catch. I'd intended to remove this behavior as it's

CRLF vs just LF in multipart parser

2009-12-15 Thread Dave Peck
Hello, I notice that Django's multipart form parser expects CRLF-style line endings. Specifically, django.http.multipartparser::parse_boudary_stream has a hardcoded expectation of '\r\n\r\n' to end a part header. Is this line ending mandated by RFCs, or is this hardcoding a mistake? I ask

Re: Python version roadmap

2009-12-15 Thread Russell Keith-Magee
On Wed, Dec 16, 2009 at 6:36 AM, James Bennett wrote: > On Tue, Dec 15, 2009 at 4:23 PM, Luke Plant wrote: >> We need a section in our release notes about dropping support for >> Python 2.3.  I was trying to write it, and I wanted to say "as >>

Re: why last_login in django.contrib.auth.models.User cannot be null?

2009-12-15 Thread Luke Plant
On Tuesday 15 December 2009 23:10:23 Matt Schinckel wrote: > I came across one today: > contrib.auth.tokens.PasswordResetTokenGenerator > has a method _make_token_with_timestamp, which uses last_login to > create the > token. This means that if someone generates a password reset > request, the

Re: Last call: #11863 (Model.objects.raw)

2009-12-15 Thread Ian Kelly
On Tue, Dec 15, 2009 at 4:31 PM, Jeremy Dunck wrote: > RawQuery.validate_sql excludes anything but selects, but Oracle uses > comments to do query hinting.  Can an Oracle person confirm that those > hints can't start the query SQL?  (Not worth holding up landing, of > course.)

Re: Last call: #11863 (Model.objects.raw)

2009-12-15 Thread Jeremy Dunck
On Tue, Dec 15, 2009 at 4:15 PM, Jacob Kaplan-Moss wrote: > Hey folks -- > > Forgot to mention it during the sprint this weekend, but I've pushed a > RC patch to #11863, Model.objects.raw(). If anyone's got any feedback, > let it fly. Otherwise, I'll be checking this in in a

Inline Template Hooks and Links

2009-12-15 Thread DrMeers
I'm not sure if the admin-ui merge will render this irrelevant or not. I'm often finding myself having to supply a custom template for admin inlines, simply because I need to add a link to the admin change form for the inline object itself (to access fields not including in the inline, or to

Re: why last_login in django.contrib.auth.models.User cannot be null?

2009-12-15 Thread Matt Schinckel
On Dec 15, 8:59 am, Sergiy Kuzmenko wrote: > I wonder if there is a particular reason why last_login field of  is not > defined as "null=True"? It makes sense to me to have it as null which would > mean that the user never logged in. Could there be any dependencies relying >

Re: why last_login in django.contrib.auth.models.User cannot be null?

2009-12-15 Thread Matt Schinckel
On Dec 15, 8:59 am, Sergiy Kuzmenko wrote: > I wonder if there is a particular reason why last_login field of  is not > defined as "null=True"? It makes sense to me to have it as null which would > mean that the user never logged in. Could there be any dependencies relying >

Re: Python version roadmap

2009-12-15 Thread James Bennett
On Tue, Dec 15, 2009 at 4:23 PM, Luke Plant wrote: > We need a section in our release notes about dropping support for > Python 2.3.  I was trying to write it, and I wanted to say "as > announced in such & such a place", but I can't actually find that > place. I know the

Python version roadmap

2009-12-15 Thread Luke Plant
Hi all, We need a section in our release notes about dropping support for Python 2.3. I was trying to write it, and I wanted to say "as announced in such & such a place", but I can't actually find that place. I know the decision was made somehow... Also, we should be adding any plans to drop

Last call: #11863 (Model.objects.raw)

2009-12-15 Thread Jacob Kaplan-Moss
Hey folks -- Forgot to mention it during the sprint this weekend, but I've pushed a RC patch to #11863, Model.objects.raw(). If anyone's got any feedback, let it fly. Otherwise, I'll be checking this in in a couple-three days or so. Jacob -- You received this message because you are subscribed

Re: adding rosetta for enhanced user experience

2009-12-15 Thread Simon Willison
On Dec 14, 9:41 pm, Suno Ano wrote: > What do folks think about shippinghttp://code.google.com/p/django-rosetta > with Django? Enabling it per default even? imho that app is totally > worth being shipped with Django per default. This came up a couple of months ago. Here's

Re: What do people think about the get_absolute_url proposal?

2009-12-15 Thread Waylan Limberg
On Tue, Dec 15, 2009 at 3:23 PM, Michael Richardson wrote: > > > On Dec 15, 4:35 am, Ivan Sagalaev wrote: >> Mike Malone wrote: >> > Well, not really. It's making a way to generate a URL based on the >> > request object global. I agree

Re: What do people think about the get_absolute_url proposal?

2009-12-15 Thread Michael Richardson
On Dec 15, 4:35 am, Ivan Sagalaev wrote: > Mike Malone wrote: > > Well, not really. It's making a way to generate a URL based on the > > request object global. I agree that it's not ideal, but it's not the > > same as just making the request object global. > > My

Re: Ticket #3349 patch review

2009-12-15 Thread Andrew Durdin
While I think of it: One thing this patch should address is updating the `contributing` page to mention calling wrap_and_raise whenever you are "catching an exception arising from user-supplied code and then raising a different

Re: Ticket #3349 patch review

2009-12-15 Thread Andrew Durdin
On Dec 14, 11:00 pm, ab wrote: > > `wrap_and_raise()` will appear in the traceback, `raise   > > wrap_exception(SomeException())` would be cleaner. > > I like that But you must use the three-argument `raise` statement to supply your own traceback in Python 2.x. You could

Re: Designing an Inventory model

2009-12-15 Thread Yusuf Mohsinally
Thanks, I'll post it there. On Tue, Dec 15, 2009 at 5:52 AM, Russell Keith-Magee wrote: > On Tue, Dec 15, 2009 at 4:17 PM, yummy_droid wrote: >> Hi, >> >> I wanted to design a system that would keep inventory data for items. >> The items themselves

Re: Designing an Inventory model

2009-12-15 Thread Russell Keith-Magee
On Tue, Dec 15, 2009 at 4:17 PM, yummy_droid wrote: > Hi, > > I wanted to design a system that would keep inventory data for items. > The items themselves are different enough, that they don't conform to > a simple model. Django-developers is for discussing the development of

Designing an Inventory model

2009-12-15 Thread yummy_droid
Hi, I wanted to design a system that would keep inventory data for items. The items themselves are different enough, that they don't conform to a simple model. E.g., the products are for a bakery company. The company keeps inventory of solid items, liquid items, and items that are used in

Re: What do people think about the get_absolute_url proposal?

2009-12-15 Thread Ivan Sagalaev
Mike Malone wrote: > Well, not really. It's making a way to generate a URL based on the > request object global. I agree that it's not ideal, but it's not the > same as just making the request object global. My main gripe is not globalness of a request object itself (I agree with "not ideal"