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

[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 his view
but I've approached such functionality as "nice to have" for the patch since
its not critical to the patch being useful.  Personally I haven't had the
time to figure it out and implement it so my original patch didn't include
it.

For the multidb approach I'd lean towards the kwargs approach.  Right now
the .raw() code is fairly well insulated from the bulk of the ORM and visa
versa.  This keeps the raw() code pretty simple and minimizes the
opportunities for introducing new bugs in the ORM.

As far as putting raw() on querysets I'd be pretty against it as well.  It
strikes me in a lot of ways as mutli-table inheritance does.  People are
really going to want it, until they try and use it in the real world, and
realize that it was a really bad idea.  While I'm sure Russ or some others
around here could work some awesome magic and get it working after a
fashion, I don't think it will ever work the way a new user will expect.
 What does performing a raw query on a queryset even mean?  In the end I
think adding .raw() to queryset would lead to a much more complicated
implementation and more confusion for users.


Sean O'Connor
http://seanoc.com


On Tue, Dec 15, 2009 at 8:24 PM, Russell Keith-Magee  wrote:

> 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 couple-three days
> > or so.
>
> Hi Jacob,
>
> A couple of quick notes on the RC2 patch:
>
>  * If you have an incomplete selection of fields, the patch currently
> marks those fields as None/default values. Couldn't (Shouldn't?) they
> be marked as deferred fields?
>
>  * Looking slightly forward - what's the integration point for
> multidb? One option is to put a using argument on raw::
>
>  Person.objects.raw('SELECT ...", using='other')
>
> It would be nice to allow .using(), but while it is easy to allow::
>
>  Person.objects.raw('SELECT ...").using('other')
>
> it isn't so easy to allow::
>
>  Person.objects.using('other').raw('SELECT ...")
>
> We could jump through some hoops to put raw() on queryset, but raise
> exceptions under most uses (i.e., if you've performed any query
> modifying operation). However, this is a lot of hoops just to allow an
> edge case API use.
>
> Obviously, multidb isn't in scope for this patch, but given the
> obvious overlap, I thought I'd ask for opinions.
>
> Other than that, RC2 looks good to me.
>
> Russ %-)
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python version roadmap

[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 proposed the roadmap. But that's Red Hat's problem; if they
> want to keep shipping ancient versions of Python, their customers
> aren't going to be able to run modern Python applications.

It's also important to note that:

 * Django 1.2 *will* be Python 2.4 compatible, so RHEL5 users will be
able to use every Django 1.2.X release.

 * Python 2.5, 2.6, 3.0 and 3.1 are available for RHEL5, albeit under
different support arrangements. Users bound to RHEL5 that simply must
use Django 1.3+ have the option of installing a different version of
Python.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Re: Python version roadmap

[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, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python version roadmap

[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 versions of Python, their customers
aren't going to be able to run modern Python applications.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python version roadmap

[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.
>
> Please note that python 2.4 is default in RHEL5.
>
> --
> Regards
> Dulmandakh
> http://www.dulmandakh.com
> http://www.twitter.com/dulmandakh/
>
> --
>
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

That's know, but the simple fact remains that that's a really old
version of python (over 5 years), and in the larger view we need to be
moving towards 2.6 and 3.0.  Nobody is required to upgrade.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python version roadmap

[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
http://www.dulmandakh.com
http://www.twitter.com/dulmandakh/

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[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 installation and upgrade order.

This is a good point. On the other hand, If an existing application relies  
on last_login not being null it would most likely continue function  
faultlessly even if the table can be null. The only exception I can think  
of would be someone attempting to try/except an error to make sure  
last_login was is not null but this does not seem to be a common practice.

I think new applications could benefit from removing not null constraint.  
And it seems to be rather safe to flip "null=False" without breaking  
backward compatibility (if password reset functionality is properly  
addressed).

Cheers
SK

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[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 couple-three days
> or so.

Hi Jacob,

A couple of quick notes on the RC2 patch:

 * If you have an incomplete selection of fields, the patch currently
marks those fields as None/default values. Couldn't (Shouldn't?) they
be marked as deferred fields?

 * Looking slightly forward - what's the integration point for
multidb? One option is to put a using argument on raw::

  Person.objects.raw('SELECT ...", using='other')

It would be nice to allow .using(), but while it is easy to allow::

  Person.objects.raw('SELECT ...").using('other')

it isn't so easy to allow::

  Person.objects.using('other').raw('SELECT ...")

We could jump through some hoops to put raw() on queryset, but raise
exceptions under most uses (i.e., if you've performed any query
modifying operation). However, this is a lot of hoops just to allow an
edge case API use.

Obviously, multidb isn't in scope for this patch, but given the
obvious overlap, I thought I'd ask for opinions.

Other than that, RC2 looks good to me.

Russ %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: CRLF vs just LF in multipart parser

[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.
>
> Is this line ending mandated by RFCs, or is this hardcoding a mistake?
>
>
Reads like mandated to me:

http://www.ietf.org/rfc/rfc2616.txt, section 3.7.2 (Multipart Types)
http://www.ietf.org/rfc/rfc2046.txt

Karen

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[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 overly
strict -- the whole point of ``raw()`` is that it lets you play fast
and loose with best practices. The code now matches the docs.

> RawQuery._populate_cache does fetchall().  This is sort of surprising,
> since normal QuerySets go out of their way to avoid fetchall.
> RawQuerySets are not as lazy as normal querysets in that normal
> querysets do fetchmany.  If this was intended, it might be worth
> pointing out.   In fact, I think RawQuerySet.iterator won't do what
> people expect.

Yeah, this is annoying: SQLite doesn't support cursor.rowcount until
all the rows have been fetched, so supporting a cheap __len__ is hard.

After thinking about it for a while I've decided just to ditch __len__
and return the raw cursor for __iter__. That's closer to the "raw"
database access anyway. Users can always ``len(list(q))`` if they
must. Nothing in the docs mentioned len() any way, and I can't see it
being all that useful -- as long as you're writing raw SQL, COUNT(*)
is going to be more efficient anyway.

> On "admonition:: Model table names" - Person._meta.db_table would have
> the value, and it might be better to be more explicit about it.  But
> it's an "_" API, so maybe we don't want to make it clearer after all.
> ;-)

I'm leaving it out deliberately -- we've avoided stabilizing _meta (so
far), so until we do (or add an official model reflection API) I'm
leaving it out of the docs.

> "You'll use ``%s``"
> Is that back-end independent?  It looks like it gets evaluated by
> whatever backend you're using, and so would depend on DB-API
> paramstyle.

Nope -- ``connection.cursor()`` returns a ``CursorWrapper`` that
translates query styles into '%s' reguardless (see
django.db.backends.sqlite3.SQLiteCursorWrapper for one example).

> RawQuery.validate_sql excludes anything but selects, but Oracle uses
> comments to do query hinting.

*** boggles ***

(Looks like it's not a problem, though.)




New patch uploaded - let me know if you see anything else.

Jacob

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

CRLF vs just LF in multipart parser

[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 because I appear to have an external client that only sends LF-
only endings; this causes Django to miss the entire contents of the
form post.

Thanks,
Dave

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python version roadmap

[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
>> 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 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.
>
> I can write the docs for this; I'd assumed that the plan of "start by
> dropping 2.3 in 1.2 and then drop one Python version in each release
> after" was what we'd be doing. If I'm wrong on this, someone please
> let me know.

This matches my understanding of the plan. The fact that it hasn't
been formally documented is a serious oversight.

Russ %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[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 token
> will be invalidated if that user then logs in. This could occur if
>  a person creates
> password reset requests for a user that is not themself.

That behaviour would occur whether or not last_login allowed nulls, 
and it is deliberate - the token is intended to be "use once", so 
logging in or setting the password changes the value of the token.

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 installation and upgrade order.

Luke

-- 
"I imagine bugs and girls have a dim suspicion that nature played a 
cruel trick on them, but they lack the intelligence to really 
comprehend the magnitude of it." (Calvin and Hobbes)

Luke Plant || http://lukeplant.me.uk/

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[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.)

Hints always immediately follow the SELECT keyword.

http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/sql_elements006.htm#i31713

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[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 couple-three days
> or so.

==
InsuficientFields -> InsufficientFields

==
This bit doesn't seem to be true; It seems that missing fields will
raise InsuficientFields instead.  Am I reading it wrong?
"
 The ``Person`` objects returned by this query will have their ``first_name``
 attributes set correctly, but *will not have any other model fields set*. This
 means that accessing ``last_name`` or ``birth_date`` will result in an
 ``AttributeError``.
"

==
RawQuery.__len__ calls _populate_cache twice.  I see the comment about
SQLite, but if that was intended, why not just use len(self._cache) to
start with, since _populate_cache does .fetchall()?

==

RawQuery._populate_cache does fetchall().  This is sort of surprising,
since normal QuerySets go out of their way to avoid fetchall.
RawQuerySets are not as lazy as normal querysets in that normal
querysets do fetchmany.  If this was intended, it might be worth
pointing out.   In fact, I think RawQuerySet.iterator won't do what
people expect.

==
On "admonition:: Model table names" - Person._meta.db_table would have
the value, and it might be better to be more explicit about it.  But
it's an "_" API, so maybe we don't want to make it clearer after all.
;-)

==
"You'll use ``%s``"
Is that back-end independent?  It looks like it gets evaluated by
whatever backend you're using, and so would depend on DB-API
paramstyle.

==
Typo here:
"It's tempting to write the above query as:: "
>>> query = 'SELECT * FROM myapp_person WHERE last_name = %s', % lname)
->
>>> query = 'SELECT * FROM myapp_person WHERE last_name = %s' % lname
Or did you make it bad syntax on purpose?

==

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

==

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Inline Template Hooks and Links

[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 implement 'recursive inlines', etc), or to display
additional details/method output. Given that the admin/edit_inline
templates contain no blocks, I am forced to duplicate the (rather
ugly) code instead of simply extending. Would it be worth submitting a
patch to include some simple hooks in these templates (e.g. before/
after each inline, before/after the inline set) to allow extension?

In addition, I wonder if it would be worth checking if the inline
model is registered in the admin itself, and if so providing a link to
its change form by default (or if the InlineModelAdmin specifies a
'show_admin_link' option or similar)?

Simon

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[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
> on this field not being null?
>

What isn't clear is that this value must be after 1900: I had used a
value of datetime(1,1,1,0,0) as "never logged in", but this fails with
password reset.

Matt.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[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
> on this field not being null?

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 token
will be invalidated if that user then logs in. This could occur if a
person creates
password reset requests for a user that is not themself.

Matt.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python version roadmap

[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 decision was made somehow...
>
> 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.

I can write the docs for this; I'd assumed that the plan of "start by
dropping 2.3 in 1.2 and then drop one Python version in each release
after" was what we'd be doing. If I'm wrong on this, someone please
let me know.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Python version roadmap

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

I don't think we have ever come to a consensus on when to drop 2.4 
support, though a year ago James Bennett made a well researched post 
suggesting that 1.2 should drop Python 2.3 support, 1.3 should drop 
Python 2.4 support, and 1.4 drop Python 2.5 support, so that we can 
then continue development against 2.6, with a Python 3.0 port.  No-one 
disagreed with that plan, but then again few people responded.  

While James' post contained a lot of details on why dropping 2.3 is 
OK, and there was consensus that coping with Python 2.3 bugs is 
significant enough to slow development and hinder the road to 3.0, I 
don't recall any similar analysis with respect to 2.4.

We really do need to be giving people warning if we are going to be 
dropping 2.4, and it needs to be in the version before it happens at 
the very least.

We could possibly say something like "1.2.X is the last series 
*guaranteed* to support Python 2.4". That way, we can postpone the 
actual decision, while encouraging people to upgrade and giving us the 
freedom to drop it if that seems like a good idea.

Luke

-- 
"I imagine bugs and girls have a dim suspicion that nature played a 
cruel trick on them, but they lack the intelligence to really 
comprehend the magnitude of it." (Calvin and Hobbes)

Luke Plant || http://lukeplant.me.uk/

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[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 to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: adding rosetta for enhanced user experience

[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 why I don't think it's
appropriate to ship with Django:

http://groups.google.com/group/django-developers/msg/bfd9c35fb95bb35a

Basically, it turns out most translators already have a preferred
toolchain and may well not want to use a web-based tool.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: What do people think about the get_absolute_url proposal?

[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 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" here) but the very idea of constructing a URL from request.
>>
>> > You wouldn't have any trouble in a standalone script unless you tried
>> > to call the get_absolute_url() function.
>>
>> But I kinda want that. Here's two more usecases where using current
>> request for creating URLs is broken:
>>
[snip]
>
> With these cases (the former more so than the latter) you are creating
> URLs for an entirely separate project, not your own, essentially.  You
> aren't creating URLs for that particular project, which is where a
> request-aware URL creation resource is intensely useful.
>
> We pass around request objects all over the place in order to get this
> functionality.  request.build_absolute_uri is great, but it does
> require that request object and passing it around - which sucks.
>
> I am 100% with Mike on this.
>

The way i see it (which may be wrong), this is not a proposal to make
the request object global or replace/refactor the contrib.site app. In
fact, some of the use cases mentioned strike me as things that would
require overriding the default get_absolute_url method anyway. It
seems to me like everyone is arguing over things outside the scope of
this proposal.

Sure, a better solution than the current site app would be nice, but
that's not on the table right now. So given the existing framework,
and knowing you can override the default very easily, is seems that
Simon's proposal fits the bill.

I was going to suggest that the method could accept a request object
as an optional argument and fall back to using the site app if no
request is provided. But if you have the request, you can get the
domain yourself and call get_url on the model. Besides, I'm not really
sure how that would translate to use from within the template system.
But wouldn't that really come under a future proposal for a
better/replacement site app? Or should the current proposal be set
aside until that is solved first?

Personally, I'd prefer this proposal to land now and hope for a better
solution to the limitations of the site app later. That way the API is
set and I can start using it. If the stuff behind the scenes changes
later that's fine.

-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: What do people think about the get_absolute_url proposal?

[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 main gripe is not globalness of a request object itself (I agree with
> "not ideal" here) but the very idea of constructing a URL from request.
>
> > You wouldn't have any trouble in a standalone script unless you tried
> > to call the get_absolute_url() function.
>
> But I kinda want that. Here's two more usecases where using current
> request for creating URLs is broken:
>
> - If I have an API part of the service and human-readable part of the
> service on different hosts and I want to construct a reference to API
> when serving user pages.
> - If have several machines behind a load-balancing proxy that's not
> under my control and that's not telling me its hostname I don't want to
> construct URLs with internal hostnames of individual machines in cluster.
>
> In other words there are legitimate real-world cases when "current"
> requests has nothing to do the URL I want to cnstruct.

With these cases (the former more so than the latter) you are creating
URLs for an entirely separate project, not your own, essentially.  You
aren't creating URLs for that particular project, which is where a
request-aware URL creation resource is intensely useful.

We pass around request objects all over the place in order to get this
functionality.  request.build_absolute_uri is great, but it does
require that request object and passing it around - which sucks.

I am 100% with Mike on this.

> > I will reiterate that, in practice, this is a huge pain in the ass.
>
> Can you provide an example? My experience doesn't match this. My only
> minor complaint is that I sometimes forget to update default
> "example.com" generated for Site model on new installation (which should
> be fixed differently, IMO).

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ticket #3349 patch review

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

Andrew.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ticket #3349 patch review

[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 dispense with the function
entirely if you're happy to repeat `import sys; raise NewException(),
None, sys.exc_info()[2]` instead--although then you lose some
information, see below.


> > Your patch seems to swallow the new exception's traceback now instead
> > of the causing traceback. That might be good in some situations, but
> > generally both should be preserved.

No; the only part of the traceback lost is the `raise` line within
`wrap_and_raise`; the remainder of the traceback which would
correspond to all but the `raise` line of the new exception's
traceback is preserved. But if you weren't using the `wrap_and_raise`
function, you would lose the line of the traceback where the new
exception was raised. Put the following code in a python script and
compare the tracebacks when it calls wrapped(), unwrapped(), or
manually_wrapped():


def wrap_and_raise(new_exception):
  import sys
  exc_class, exc, tb = sys.exc_info()
  if issubclass(exc_class, Exception):
raise new_exception, None, tb
  else:
raise new_exception

def valueerror():
  raise ValueError("This is a ValueError")

def wrapped():
  try:
valueerror()
  except:
wrap_and_raise(StandardError("This error normally hides the
original error"))

def unwrapped():
  try:
valueerror()
  except:
raise StandardError("This error hides the original error")

def manually_wrapped():
  import sys
  try:
valueerror()
  except:
raise StandardError("This error normally hides the original
error"), None, sys.exc_info()[2]

# Try each of these
wrapped()
# unwrapped()
# manually_wrapped()



> > Better yet, make all exceptions that are used to reraise other  
> > exceptions a subclass of WrappingException (pick a better name) that  
> > either takes a `cause=exc` or `wrap=True` kwarg. This way, you don't  
> > have to add imports everywhere.
>
> I don't like that. An invalid template exception might be "wrapping"
> sometimes, but not others.

TemplateSyntaxError is an obvious example. Also, if you do this you're
still not preserving the original traceback.


> Another question: how should the tests for this ticket be written?

I'm not sure (which is why I didn't write any tests originally).
Obviously you'd raise an exception, catch it, and wrap_and_raise
another. I suppose you could examine the output of
`traceback.format_exc()` or one of its other functions to see if the
original exception is now mentioned in the traceback.

Andrew.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Designing an Inventory model

[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 are different enough, that they don't conform to
>> a simple model.
>
> Django-developers is for discussing the development of Django itself.
> General user usage queries should be directed to django-users.
>
> Yours,
> Russ Magee %-)
>
> --
>
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Designing an Inventory model

[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 Django itself.
General user usage queries should be directed to django-users.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Designing an Inventory model

[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
partial quantities. Each has its own properties, some have volume,
some have wieght, some have length, etc.

So, should I try to create a base "Item" model, which common
attributes like name and vendor_id, and then have a one-to-many
relationship to a table which you can add custom fields/value pairs.
(i would like to be able to choose a "category" when creating a new
item, and have the form automatically show the fields for that item).

Or, should I go about creating a base "Item" class, and then subclass
it for each category of item?

My main concern is that the system is built in such a way that we can
easily create future reports across all the inventory database (e.g.
what is the time any item has been in the store room, price of
inventory of same type for all items, etc.), without having to worry
about the way we implemented the models.\

Thanks.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: What do people think about the get_absolute_url proposal?

[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" here) but the very idea of constructing a URL from request.

> You wouldn't have any trouble in a standalone script unless you tried
> to call the get_absolute_url() function.

But I kinda want that. Here's two more usecases where using current 
request for creating URLs is broken:

- If I have an API part of the service and human-readable part of the 
service on different hosts and I want to construct a reference to API 
when serving user pages.
- If have several machines behind a load-balancing proxy that's not 
under my control and that's not telling me its hostname I don't want to 
construct URLs with internal hostnames of individual machines in cluster.

In other words there are legitimate real-world cases when "current" 
requests has nothing to do the URL I want to cnstruct.

> I will reiterate that, in practice, this is a huge pain in the ass.

Can you provide an example? My experience doesn't match this. My only 
minor complaint is that I sometimes forget to update default 
"example.com" generated for Site model on new installation (which should 
be fixed differently, IMO).

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.