Re: Why not use @classmethod decorator consitently in django/utils/functional.py?

[Adam Smith]

Hi Shai,

Just FYI, on github @charettes merge my PR replacing almost all `meth = 
classmethod(meth)` with `@classmethod`.

So I assume you guys are going to drop support for python2.4 and older, 
right?


Best Regards
Adam 

 

 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1fc2612a-d127-45f6-982c-81354e7d75cd%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Why not use @classmethod decorator consitently in django/utils/functional.py?

[Baptiste Mispelon]

Hi Adam,

Django 1.6 only supports Python 2.6 and older [1] and Django 1.7 will 
support Python 2.7 onwards [2].


[1] https://docs.djangoproject.com/en/1.6/releases/1.6/#python-compatibility
[2] https://docs.djangoproject.com/en/dev/releases/1.7/#python-compatibility

Cheers,
Baptiste

On 11/20/2013 10:39 AM, Adam Smith wrote:

Hi Shai,

Just FYI, on github @charettes merge my PR replacing almost all
`meth = classmethod(meth)` with `@classmethod`.

So I assume you guys are going to drop support for python2.4 and
older, right?


Best Regards
Adam

--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1fc2612a-d127-45f6-982c-81354e7d75cd%40googlegroups.com.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/528C857D.6090200%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Why not use @classmethod decorator consitently in django/utils/functional.py?

[Adam Smith]

You are right, I should have checked out those release notes.

Thanks Baptiste!

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/04634188-cf5b-4815-8ec1-e85cf2434751%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Related manager remove() and clear() methods - backwards incompatible changes

[Shai Berger]

Hi,

On Saturday 16 November 2013 21:02:00 Anssi Kääriäinen wrote:
> Any feedback for pre/post_update idea?
> 
As Loic said, the signals sound like they can be useful in a variety of 
situations. A couple of notes, though:

> pre_update listeners get a queryset that isn't executed.

The "query" part, only, I assume; then they should also somehow get the 
intended update parameters. Perhaps the actual keyword arguments to update().

> Accessing that queryset might be costly

Accessing objects from that queryset may be a footgun -- if they somehow stay 
in memory after the update is executed, they will become stale. There should 
be stern warnings about this in the documentation, or even -- and this is just 
thinking outloud, I haven't considered all the evil effects -- holding weakrefs 
to all these objects and using the new model reload mechanism to refresh them 
after the update.

Shai.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201311201717.11988.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

db_type is called more than documented.

[schinckel]

I maintain the django-jsonfield module, and I have, as the documentation 
suggests, some relatively expensive code in JSONField.db_type.

The documentation is pretty clear on this as being _the_ place to put a 
test like this (that checks to see if the database can handle a json field 
type, or if we should just store it as text).


https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#custom-database-types

"The 
db_type()
 method 
is only called by Django when the framework constructs the CREATE TABLE 
statements 
for your application – that is, when you first create your tables. It’s not 
called at any other time, so it can afford to execute slightly complex 
code, such as the connection.settings_dict check in the above example."

However, I noticed that the SQL query I was running to check for if I 
should use a json field was running way more than expected.

It turns out that this method is called at:


https://github.com/django/django/blob/master/django/db/models/sql/where.py#L368

All other calls to this method appear to be in CREATE statements.

Is this something that just slipped under the radar? Is it something that 
should be fixed in documentation? Any suggestions?

Regards,

Matt.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3b0084b2-da32-420b-a9b1-dc4bcd4ffe46%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.