Re: Inappropriate behavior [was: Re: default delete() clear() behavior and you.]

[Kevin Howerton]

sorry.  my intention wasn't to make light of violence of any nature.
the image i posted was an actual ad for las vegas.  i just returned
from there (for the millionth time, i have family that live there..
not the biggest fan of vegas) ... and thus it was on my mind.  i will
contain my sardonic wit henceforth, as it clearly doesn't translate
well on the internet.

sorry again.

-k

On Tue, Apr 6, 2010 at 12:14 AM, Jacob Kaplan-Moss  wrote:
> On Mon, Apr 5, 2010 at 1:06 PM, Kevin howerton  
> wrote:
>> ps.  I didn't really murder a hooker in vegas
>
> This sort of "joke" is highly offensive, and isn't appropriate here.
> Frankly, I don't think it's appropriate *anywhere*, but I actually
> have some power to stop this sort of crap here, and I'm using it.
>
> Violence against women and sex workers is very real, and joking about
> it trivializes the very real pain of survivors. The image you posted
> could have been highly hurtful to those who've experienced violence;
> images and jokes about sexualized violence trigger painful memories.
>
> I recognize that you probably didn't intend to offend. Nevertheless,
> you did: I found your "joke" offensive and tasteless, and the image
> you posted more so. Discriminatory and exclusionary humor causes real
> pain and is not appropriate here.
>
> 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: default delete() clear() behavior and you.

[Florian Apolloner]

Hi,

On Apr 6, 12:19 am, Kevin Howerton  wrote:
> I only killed one hooker, but it was really small so I don't know if it 
> counts.
Hmmm…

> The problem with those patches though are that they don't appear
> (correct me if i'm wrong) to account for handling different deletes
> per reverse relation.  You really need to have a more granular
> approach.  If an object has two parents pointing at it; one with NULL,
> and one with a DEFAULT set... how would you be able to have it handle
> the different behavior on both?
I won't; the database takes care of it, if I delete the object the
foreignkey from parent1->object will get set to null and the
foreignkey from parent2->object will get set to the default. (see
http://www.postgresql.org/docs/8.4/static/ddl-constraints.html#DDL-CONSTRAINTS-FK
for more info, I guess it becomes clearer when you see it in a non orm
context)

> Also, regardless of whether an elegant solution that relies on the
> database exists for the delete method, I feel like the clear method
> should be patched to match the behavior of the code I posted.
Yes, I hope this will land together with ON_UPDATE/ON_DELETE support.

I hope I didn't confuse you more than necessary ;)

Cheers,
Florian

-- 
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: default delete() clear() behavior and you.

[Kevin Howerton]

I only killed one hooker, but it was really small so I don't know if it counts.

The problem with those patches though are that they don't appear
(correct me if i'm wrong) to account for handling different deletes
per reverse relation.  You really need to have a more granular
approach.  If an object has two parents pointing at it; one with NULL,
and one with a DEFAULT set... how would you be able to have it handle
the different behavior on both?  It seems like the patches mentioned
in that ticket would only allow you to either delete(cascade=defaults)
or delete(cascade=nulls)... when you really need it to vary based on
the parent field.  Not sure what whether all of the databases can
handle that behavior?

Also, regardless of whether an elegant solution that relies on the
database exists for the delete method, I feel like the clear method
should be patched to match the behavior of the code I posted.

-k
On Mon, Apr 5, 2010 at 5:20 PM, Florian Apolloner  wrote:
> Uhm, your fix fixes the problem at the wrong end. This can and should
> be supported by the database's native capabilities. This would be the
> ticket for it: http://code.djangoproject.com/ticket/7539
>
> But I like your imagination, or is there more truth behind your story
> than you'd admit?
>
> Cheers,
> Florian Apolloner
>
> On Apr 5, 8:06 pm, Kevin howerton  wrote:
>> Hi.
>>
>> So I came across a use-case for wanting to delete content (which
>> django doesn't really handle exactly to my liking).  I just got back
>> from a vacation in vegas and noticed in a drunken stupor I had posted
>> some pictures on my blog that should I really shouldn't have 
>> (http://i.imgur.com/5oj15.jpgSFW).
>>
>> Anyhow, currently django's only delete behavior (to my knowledge) is
>> to delete all objects related from a reverse relation.  I think it
>> would be preferable to actually delete only objects that have NOT NULL
>> **and** no default set.
>>
>> Right now clear() sort of fills some of the void for what you need to
>> do prior to deleting an object, but it fails to handle DEFAULT
>> conditions.
>>
>> I realize changing the default behavior of the delete() method is
>> probably out of the question... and there are a bunch of tickets open
>> asking for cascades and what-not, that will hopefully one day fill the
>> void.  clear(), however, *should* handle DEFAULTS in the same way it
>> handles null=True.
>>
>> Also, I wrote a mix-in class that fixes the delete method to work as I
>> believe it should... for those of you with similar use-cases.  Anyone
>> have any feedback on it?
>>
>> ps.  I didn't really murder a hooker in vegas (I don't even have a
>> blog), just felt that I should provide a relevant use-case ;)
>>
>> from django.db.models.fields import NOT_PROVIDED
>> from django.contrib import admin
>>
>> class ClearOnDelete(models.Model):
>>     def delete(self):
>>         related_objects = self._meta.get_all_related_objects()
>>         for object in related_objects:
>>             accessor_name = object.get_accessor_name()
>>             related_accessor = getattr(self.__class__, accessor_name)
>>             related_accessor_instance = getattr(self, accessor_name)
>>
>>             if related_accessor.related.field.default is not
>> NOT_PROVIDED:
>>                 for relation in related_accessor_instance.all():
>>                     setattr(relation,
>> related_accessor.related.field.name,
>> related_accessor.related.field.default)
>>                     relation.save()
>>             elif related_accessor.related.field.null:
>>                 for relation in related_accessor_instance.all():
>>                     setattr(relation,
>> related_accessor.related.field.name, None)
>>                     relation.save()
>>         super(ClearOnDelete, self).delete()
>>
>>     class Meta:
>>         abstract = True
>
> --
> 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: default delete() clear() behavior and you.

[Florian Apolloner]

Uhm, your fix fixes the problem at the wrong end. This can and should
be supported by the database's native capabilities. This would be the
ticket for it: http://code.djangoproject.com/ticket/7539

But I like your imagination, or is there more truth behind your story
than you'd admit?

Cheers,
Florian Apolloner

On Apr 5, 8:06 pm, Kevin howerton  wrote:
> Hi.
>
> So I came across a use-case for wanting to delete content (which
> django doesn't really handle exactly to my liking).  I just got back
> from a vacation in vegas and noticed in a drunken stupor I had posted
> some pictures on my blog that should I really shouldn't have 
> (http://i.imgur.com/5oj15.jpgSFW).
>
> Anyhow, currently django's only delete behavior (to my knowledge) is
> to delete all objects related from a reverse relation.  I think it
> would be preferable to actually delete only objects that have NOT NULL
> **and** no default set.
>
> Right now clear() sort of fills some of the void for what you need to
> do prior to deleting an object, but it fails to handle DEFAULT
> conditions.
>
> I realize changing the default behavior of the delete() method is
> probably out of the question... and there are a bunch of tickets open
> asking for cascades and what-not, that will hopefully one day fill the
> void.  clear(), however, *should* handle DEFAULTS in the same way it
> handles null=True.
>
> Also, I wrote a mix-in class that fixes the delete method to work as I
> believe it should... for those of you with similar use-cases.  Anyone
> have any feedback on it?
>
> ps.  I didn't really murder a hooker in vegas (I don't even have a
> blog), just felt that I should provide a relevant use-case ;)
>
> from django.db.models.fields import NOT_PROVIDED
> from django.contrib import admin
>
> class ClearOnDelete(models.Model):
>     def delete(self):
>         related_objects = self._meta.get_all_related_objects()
>         for object in related_objects:
>             accessor_name = object.get_accessor_name()
>             related_accessor = getattr(self.__class__, accessor_name)
>             related_accessor_instance = getattr(self, accessor_name)
>
>             if related_accessor.related.field.default is not
> NOT_PROVIDED:
>                 for relation in related_accessor_instance.all():
>                     setattr(relation,
> related_accessor.related.field.name,
> related_accessor.related.field.default)
>                     relation.save()
>             elif related_accessor.related.field.null:
>                 for relation in related_accessor_instance.all():
>                     setattr(relation,
> related_accessor.related.field.name, None)
>                     relation.save()
>         super(ClearOnDelete, self).delete()
>
>     class Meta:
>         abstract = True

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

Talk on django to an enterprise audience

[Lakshman Prasad]

Hi,

I will be speaking about django "Building Reusable Applications using
django" at the Great Indian Developer summit
(link)
in a couple of weeks.

GIDS is a large conference, with lot of enterprise audience. To most of
them, this will be an introduction to django. I have spoken about django to
local user groups and at some conferences before
(1
 
2
 3 ).

So, wrt this talk at the conference,

* I have seen several threads that touch about on
"django-for-the-enterprise", I solicit the community feedback about the
specific content that needs to be highlighted. If core developers and/or
BDFLs have something to say, I will be glad.

* I think Jacob's presentation
http://www.slideshare.net/jacobian/django-introduction-dev-in-rio-2009 is
awesome and if allowed, I would love to shamelessly copy a few slides and
patterns.

-- 
Lakshman
http://stackoverflow.com/users/55562/becomingguru

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

default delete() clear() behavior and you.

[Kevin howerton]

Hi.

So I came across a use-case for wanting to delete content (which
django doesn't really handle exactly to my liking).  I just got back
from a vacation in vegas and noticed in a drunken stupor I had posted
some pictures on my blog that should I really shouldn't have (
http://i.imgur.com/5oj15.jpg SFW).

Anyhow, currently django's only delete behavior (to my knowledge) is
to delete all objects related from a reverse relation.  I think it
would be preferable to actually delete only objects that have NOT NULL
**and** no default set.

Right now clear() sort of fills some of the void for what you need to
do prior to deleting an object, but it fails to handle DEFAULT
conditions.

I realize changing the default behavior of the delete() method is
probably out of the question... and there are a bunch of tickets open
asking for cascades and what-not, that will hopefully one day fill the
void.  clear(), however, *should* handle DEFAULTS in the same way it
handles null=True.

Also, I wrote a mix-in class that fixes the delete method to work as I
believe it should... for those of you with similar use-cases.  Anyone
have any feedback on it?

ps.  I didn't really murder a hooker in vegas (I don't even have a
blog), just felt that I should provide a relevant use-case ;)

from django.db.models.fields import NOT_PROVIDED
from django.contrib import admin

class ClearOnDelete(models.Model):
def delete(self):
related_objects = self._meta.get_all_related_objects()
for object in related_objects:
accessor_name = object.get_accessor_name()
related_accessor = getattr(self.__class__, accessor_name)
related_accessor_instance = getattr(self, accessor_name)

if related_accessor.related.field.default is not
NOT_PROVIDED:
for relation in related_accessor_instance.all():
setattr(relation,
related_accessor.related.field.name,
related_accessor.related.field.default)
relation.save()
elif related_accessor.related.field.null:
for relation in related_accessor_instance.all():
setattr(relation,
related_accessor.related.field.name, None)
relation.save()
super(ClearOnDelete, self).delete()

class Meta:
abstract = True

-- 
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: GSOC proposal for "App loading"

[Alex Gaynor]

On Mon, Apr 5, 2010 at 12:48 PM, Dagvadorj Galbadrakh
 wrote:
> I am planning to modify django.utils.importlib.py this way. Is it
> agreeable?
>
>
> On Apr 5, 11:11 am, Dagvadorj Galbadrakh  wrote:
>> Hello group,
>>
>> I want to attend to this year's Google Summer of Code program with
>> "App loading". The following is a part from my proposal. It offers
>> more simplistic approach than heavily discussed one with App() in
>> INSTALLED_APPS, i.e., multiple instances of an app is declared as
>> ('foo.polls', 'mayor'). I'd appreciate any comments and feedbacks.
>>
>> Thanks,
>>
>> --
>>
>> Proposal
>>
>> I'd like to propose a solution which is one of the earlier
>> recommendations regarding the issue and is simpler among these. App
>> loading would be defined as follows:
>>
>> Note: The explanations and illustrations in this proposal will focus
>> around an application called 'gsoc' – Google Summer of Codes program
>> classified system which shows the lists of accepted organizations and
>> ideas of a selected organization. The instances of the app will be
>> classified systems for this year, last year, and so forth.
>>
>> INSTALLED_APPS = (
>>
>> 'django.contrib.auth',
>>
>> 'django.contrib.contenttypes',
>>
>> 'django.contrib.sessions',
>>
>> 'django.contrib.sites',
>>
>> 'django.contrib.admin',
>>
>> 'foo.gsoc', #an instance of foo.gsoc; the name is foo.gsoc
>>
>> ('foo.gsoc', '2008'), #an instance of foo.gsoc; the name is foo.gsoc_2008_
>>
>> ('foo.gsoc', '2009'), #an instance of foo.gsoc; the name is foo.gsoc_2009_
>>
>> )
>>
>> This way no names would be colliding since it relies on the uniquely
>> defined full module names (kind of namespace).
>>
>> The URLconf will be like the following:
>>
>> urlpatterns = patterns('',
>>
>> (r'^gsoc/', include('foo.gsoc.urls')),
>>
>> (r'^gsoc2009/', include('foo.gsoc_2009_.urls')),
>>
>> (r'^gsoc2008/', include('foo.gsoc_2008_.urls')),
>>
>> (r'^admin/', include(admin.site.urls)),
>>
>> )
>>
>> There's no need to define URLconf for each instance. The URLconf of
>> each instance is derived from foo/gsoc/urls.py, which in this example
>> looks like:
>>
>> from django.conf.urls.defaults import *
>>
>> import views # notice not absolute. IMPORTANT: Siblings are imported 
>> relatively.
>>
>> urlpatterns = patterns('',
>>
>> (r'^/', views.index),
>>
>> (r'^orgs/$', views.list_orgs),
>>
>> (r'^ideas/(?P\w+)/$', views.list_ideas),
>>
>> )
>>
>> In fact, I did work on the Django source trunk in the last couple of
>> days and made it work. The patch can be found here and my project
>> here.
>>
>> The major trick of my work was creating name for an instance and
>> importing it as module (like followings):
>>
>> ...
>>
>> for app_name in settings.INSTALLED_APPS:
>>
>>     if (type(app_name) == types.TupleType):
>>
>>     a = app_name[0]+ "_" + app_name[1] + "_"
>>
>> else:
>>
>>     a = app_name
>>
>> if a in self.handled:
>>
>>     continue
>>
>> ...
>>
>> # in django/db/models/loading.py and some other places
>>
>> def import_module(name, package=None):
>>
>> ...
>>
>>     if not name.split('.')[-1].endswith('_'):
>>
>>   __import__(name)
>>
>>     else:
>>
>>   temp_name = name[0:name.rindex('_')]
>>
>>   new_module = __import__(temp_name[0:temp_name.rindex('_')],
>> globals(), locals(), ['models'], -1)
>>
>>    sys.modules[name] = new_module
>>
>> return sys.modules[name]
>>
>> # in django/utils/importlib.py
>>
>> --
>> Dagvadorj GALBADRAKH
>
> --
> 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.
>
>

Err, no, modifying a set of functions who's purpose is to support
dynamic imports using the standard python import protocol should
definitely not be necessary.  I'd highly advise you take a look at the
thread on the same topic by Arthur Koziel, that thread discusses a lot
of issues that you haven't brought up here.

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: GSOC proposal for "App loading"

[Dagvadorj Galbadrakh]

I am planning to modify django.utils.importlib.py this way. Is it
agreeable?


On Apr 5, 11:11 am, Dagvadorj Galbadrakh  wrote:
> Hello group,
>
> I want to attend to this year's Google Summer of Code program with
> "App loading". The following is a part from my proposal. It offers
> more simplistic approach than heavily discussed one with App() in
> INSTALLED_APPS, i.e., multiple instances of an app is declared as
> ('foo.polls', 'mayor'). I'd appreciate any comments and feedbacks.
>
> Thanks,
>
> --
>
> Proposal
>
> I'd like to propose a solution which is one of the earlier
> recommendations regarding the issue and is simpler among these. App
> loading would be defined as follows:
>
> Note: The explanations and illustrations in this proposal will focus
> around an application called 'gsoc' – Google Summer of Codes program
> classified system which shows the lists of accepted organizations and
> ideas of a selected organization. The instances of the app will be
> classified systems for this year, last year, and so forth.
>
> INSTALLED_APPS = (
>
> 'django.contrib.auth',
>
> 'django.contrib.contenttypes',
>
> 'django.contrib.sessions',
>
> 'django.contrib.sites',
>
> 'django.contrib.admin',
>
> 'foo.gsoc', #an instance of foo.gsoc; the name is foo.gsoc
>
> ('foo.gsoc', '2008'), #an instance of foo.gsoc; the name is foo.gsoc_2008_
>
> ('foo.gsoc', '2009'), #an instance of foo.gsoc; the name is foo.gsoc_2009_
>
> )
>
> This way no names would be colliding since it relies on the uniquely
> defined full module names (kind of namespace).
>
> The URLconf will be like the following:
>
> urlpatterns = patterns('',
>
> (r'^gsoc/', include('foo.gsoc.urls')),
>
> (r'^gsoc2009/', include('foo.gsoc_2009_.urls')),
>
> (r'^gsoc2008/', include('foo.gsoc_2008_.urls')),
>
> (r'^admin/', include(admin.site.urls)),
>
> )
>
> There's no need to define URLconf for each instance. The URLconf of
> each instance is derived from foo/gsoc/urls.py, which in this example
> looks like:
>
> from django.conf.urls.defaults import *
>
> import views # notice not absolute. IMPORTANT: Siblings are imported 
> relatively.
>
> urlpatterns = patterns('',
>
> (r'^/', views.index),
>
> (r'^orgs/$', views.list_orgs),
>
> (r'^ideas/(?P\w+)/$', views.list_ideas),
>
> )
>
> In fact, I did work on the Django source trunk in the last couple of
> days and made it work. The patch can be found here and my project
> here.
>
> The major trick of my work was creating name for an instance and
> importing it as module (like followings):
>
> ...
>
> for app_name in settings.INSTALLED_APPS:
>
>     if (type(app_name) == types.TupleType):
>
>     a = app_name[0]+ "_" + app_name[1] + "_"
>
> else:
>
>     a = app_name
>
> if a in self.handled:
>
>     continue
>
> ...
>
> # in django/db/models/loading.py and some other places
>
> def import_module(name, package=None):
>
> ...
>
>     if not name.split('.')[-1].endswith('_'):
>
>   __import__(name)
>
>     else:
>
>   temp_name = name[0:name.rindex('_')]
>
>   new_module = __import__(temp_name[0:temp_name.rindex('_')],
> globals(), locals(), ['models'], -1)
>
>    sys.modules[name] = new_module
>
> return sys.modules[name]
>
> # in django/utils/importlib.py
>
> --
> Dagvadorj GALBADRAKH

-- 
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: High Level Discussion about the Future of Django

[orokusaki]

@Everyone who has commented here.

I never intended to cause any animosity and I really appreciate
everything that the core team does for us all.

@Jacob

I really do intend to write code. I make money doing non-Django
development but I love Django so much that I spend 25+ hours a week
not getting paid just so I can learn to adopt Django and eventually
replace my income with Django development. I think I might even be
part pony (DNA testing underway). There are just certain elements of
Django that I feel (slightly) holds back a developer of large multi-
tenant architecture, which could be a really big way to get major
enterprises on-board, and this is where I intend to contribute the
most. I just don't have the time (or money after Uncle Sam's 30k this
March) to spend on contributing if I'm not sure my ideas will be
accepted. This is why I want to spend a little time getting the 5,000
foot view so that my ideas are in sync with what users want, what the
core team will accept and what works best with ``from future import
*``.

If I spend 100% more time on preparing to save 50% of my time, I'll be
happy because I've learned more.

@Russell

Thanks for indulging in conversation, if just for the meta thoughts,
this is precisely the sort of macro conversation that helps me
understand the Django process's rationale.

-- 
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: High Level Discussion about the Future of Django

[Dennis Kaarsemaker]

On ma, 2010-04-05 at 23:25 +0800, Russell Keith-Magee wrote:

> I'll freely admit that despite the major improvements landing in 1.2,
> the development cycle itself hasn't been flawless. Hopefully I've been
> able to provide some explanation for why things ended up the way they
> did.

You have, thank you very much.

> So - tl;dr:
> 
>  * Yes, with hindsight, we probably should have cut a 1.1.2 release
>  * We probably should have cut that release somewhere around the start
> of March

Agreed.

>  * We're close enough to 1.2 that we're not going to cut a 1.1.X
> release until 1.2-final

Agreed again.

>  * Direct feedback from the #django and django-users trenches might
> have avoided this problem
>  * We'll try to do better next time. 

I will try to do better as well, bringing up often-reported problems on
the -developers mailing list.
-- 
Dennis K.

They've gone to plaid!

-- 
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: High Level Discussion about the Future of Django

[Russell Keith-Magee]

On Mon, Apr 5, 2010 at 10:35 PM, Dennis Kaarsemaker
 wrote:
> On ma, 2010-04-05 at 21:47 +0800, Russell Keith-Magee wrote:
>
>> The bit that I have been engaging with is the discussion of (and
>> apparent misconceptions around) Django's backwards compatibility
>> policy, and our policies regarding support for older Python versions.
>
> And I appreciate that you have done so, thanks!
>
>> However, even these discussions have limited interest for me unless
>> they rapidly converge on a *specific* criticism or problem that
>> requires rectification.
>
> Not a criticism per se, but I am wondering why the next 1.1.x is
> released alongside 1.2 instead of as a release on its own. I've yet
> again seen a case of python 2.6.5 breaking django tests, so I would
> welcome a new release of 1.1.x a bit sooner than 1.2, if only from a
> #django support perspective.

The release of 1.2 will be the point at which 1.1 moves into security
maintenance mode, so it makes sense that we cut both 1.2 and a 1.1.X
release at the same time (to make sure 1.1.X contains as many bug
fixes as possible before it moves into maintenance mode).

So, there will always be *a* 1.1.X release when we release 1.2 - the
only question is whether we release (or at this point, should have
released) an interim 1.1.2, and then make 1.1.3 the 'final' 1.1
release? The problem here is that there hasn't been a single time
where cutting 1.1.2 was both appropriate, and the importance of
cutting an interim release was known.

If you take the 1.1 development cycle as a guide, we cut a 1.0 point
release when we released 1.1-beta1. However, at the time of 1.2-beta1,
the 1.1.X branch didn't actually contain all that much, so there
wasn't much point cutting a 1.1.2 release. If we'd cut a release then,
It wouldn't have included the fix for the Python 2.6.5 problems you
are talking about.

Another useful trigger might have been the point at which we passed
our original RC date (early March). If we'd cut 1.1.2 then, we would
have fixed the 1.1.2 problems - but here, we hit a communication
problem. While I was aware that the Python 2.6.5 had problems with
1.1.1 (I fixed the bug, after all), I wasn't really aware that this
was a problem in practice for a significant body of users until about
a week or so ago.

This isn't a blame thing - I'm just pointing out that if there is a
recurring problem on IRC support (or django-users for that matter),
that doesn't necessarily mean that the core team are also aware of the
problem. And even if we are aware of the problem, it doesn't mean we
are aware of the scope of the problem, and have made plans to address
it.

Django has a huge community, and the core team can't be everywhere all
the time. We really do rely on the active members of our community to
help us identify problems as they emerge. If you're doing your share
of the heavy lifting in #django or django-users (and I know you are,
Dennis, so a big thanks for that), we're certainly interested in
hearing anything that you think will make your life easier. A quick
message to django-dev explaining the problem will sometimes be all it
takes to set the wheels in motion.

So that brings us to the present day -- at this point, we're hopefully
just a week or two away from RC, so there isn't much incentive to turn
the handle and produce a release, just to turn it again in a couple of
weeks for a second release that will only contain minor differences. I
know it's a dangerous to start singing 'tomorrow is only a day away',
but the time we spend cutting a release only serves to delay the final
release of 1.2 a little bit more.

I'll freely admit that despite the major improvements landing in 1.2,
the development cycle itself hasn't been flawless. Hopefully I've been
able to provide some explanation for why things ended up the way they
did.

So - tl;dr:

 * Yes, with hindsight, we probably should have cut a 1.1.2 release
 * We probably should have cut that release somewhere around the start of March
 * We're close enough to 1.2 that we're not going to cut a 1.1.X
release until 1.2-final
 * Direct feedback from the #django and django-users trenches might
have avoided this problem
 * We'll try to do better next time.

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: High Level Discussion about the Future of Django

[Karen Tracey]

On Mon, Apr 5, 2010 at 10:35 AM, Dennis Kaarsemaker
wrote:

> Not a criticism per se, but I am wondering why the next 1.1.x is
> released alongside 1.2 instead of as a release on its own. I've yet
> again seen a case of python 2.6.5 breaking django tests, so I would
> welcome a new release of 1.1.x a bit sooner than 1.2, if only from a
> #django support perspective.
>

The problem is if we release Django 1.1.2 now, we still need another Django
1.1.X release simultaneously with 1.2 to package in an official release all
remaining bug fixes backported to the 1.1.X branch before 1.2 is finalized.
That would make for two very close together 1.1.X releases, which is
generally not appreciated by users, though I realize it would be appreciated
by early users of Python 2.6.5. Unfortunately the timing of Python 2.6.5 and
Django 1.2 is a bit unfortunate here...for those who are quickly moving to
Python 2.6.5 the best thing to do is run with a checkout of the 1.1.X
branch.

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: High Level Discussion about the Future of Django

[Dennis Kaarsemaker]

On ma, 2010-04-05 at 21:47 +0800, Russell Keith-Magee wrote:

> The bit that I have been engaging with is the discussion of (and
> apparent misconceptions around) Django's backwards compatibility
> policy, and our policies regarding support for older Python versions.

And I appreciate that you have done so, thanks!

> However, even these discussions have limited interest for me unless
> they rapidly converge on a *specific* criticism or problem that
> requires rectification. 

Not a criticism per se, but I am wondering why the next 1.1.x is
released alongside 1.2 instead of as a release on its own. I've yet
again seen a case of python 2.6.5 breaking django tests, so I would
welcome a new release of 1.1.x a bit sooner than 1.2, if only from a
#django support perspective.

-- 
Dennis K.

They've gone to plaid!

-- 
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: High Level Discussion about the Future of Django

[ShawnMilo]

On Apr 5, 2010, at 9:31 AM, Jerome Leclanche wrote:

> Without trying to defend anyone or anything here... Why ask other
> developers to ignore an otherwise healthy discussion?
> I believe Russ engaged in the discussion because he's interested; if
> not in the idea, at least in discussing it. Not everything has to be
> backed up with code...
> 
> J. Leclanche / Adys

I don't know Jacob, and I'm not a Django contributor of any kind (at least not 
yet). So this is entirely my own opinion. What I'm suspect the problem is is 
that, although the discussion is just jabber among some random people on a 
mailing list, the topic of discussion is ultimately what those random people 
believe the core contributors ought to be spending their time on -- if not now, 
then in the future. 

So if some people want to engage in this conversation, then that's fine. But 
there's very little chance of it having any effect on Django unless it:

1. Is inline with the well-established strategies in place for making changes 
(especially backwards-incompatible changes).
2. Someone is willing to step up and do the work. 

It's not reasonable to expect the creators and core committers to ever have the 
time and energy to do something like what is being discussed here. However, if 
you have the time and energy and put in some work, you have a foot in the door 
to start a real conversation regarding getting your changes merged into trunk 
at some point.

I think that it's good to remember, every once in a while, that Django is not a 
commercial product. It's all well and good to bitch that Apple's iPad doesn't 
have a camera, or that Windows 7 has this or that flaw, or that your car's gas 
mileage sucks. But an all-volunteer open-source project is completely 
different. Just because certain individuals have stepped forward and shown that 
they can shoulder the burden of doing regular releases, maintaining old 
releases for security, and generally being awesome doesn't mean they work for 
us. It's like us trying to tell the best, smartest, and most active 
contributors to this mailing list how they could do a better job helping us. 
It's a disincentive to them, and makes us look like ingrates.

Shawn

-- 
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: High Level Discussion about the Future of Django

[Jerome Leclanche]

Without trying to defend anyone or anything here... Why ask other
developers to ignore an otherwise healthy discussion?
I believe Russ engaged in the discussion because he's interested; if
not in the idea, at least in discussing it. Not everything has to be
backed up with code...

J. Leclanche / Adys

On Mon, Apr 5, 2010 at 4:03 PM, Jacob Kaplan-Moss  wrote:
> On Sun, Apr 4, 2010 at 10:02 PM, orokusaki  wrote:
>> This is a bit abstract, but I'd like to bring up this idea, [...]
>
> Well, I'm sorry, but I just don't have time to engage on big abstract
> discussions like this, so feel free to write whatever you want, but
> don't count on my participation. I'm also going to suggest the other
> core Django developers similarly ignore this discussion, though I see
> you've managed to get Russ to engage.
>
> I do appreciate your enthusiasm, but you seem to have forgotten a
> basic tenant of open source: there's one -- and only one -- way of
> getting your way:
>
> Write code.
>
> Show me code, and I'll pay attention to your proposals. Show me big
> crazy abstract "what ifs" and I, well, won't.
>
> 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.
>
>

-- 
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: High Level Discussion about the Future of Django

[Jacob Kaplan-Moss]

On Sun, Apr 4, 2010 at 10:02 PM, orokusaki  wrote:
> This is a bit abstract, but I'd like to bring up this idea, [...]

Well, I'm sorry, but I just don't have time to engage on big abstract
discussions like this, so feel free to write whatever you want, but
don't count on my participation. I'm also going to suggest the other
core Django developers similarly ignore this discussion, though I see
you've managed to get Russ to engage.

I do appreciate your enthusiasm, but you seem to have forgotten a
basic tenant of open source: there's one -- and only one -- way of
getting your way:

Write code.

Show me code, and I'll pay attention to your proposals. Show me big
crazy abstract "what ifs" and I, well, won't.

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.

GSOC proposal for "App loading"

[Dagvadorj Galbadrakh]

Hello group,



I want to attend to this year's Google Summer of Code program with
"App loading". The following is a part from my proposal. It offers
more simplistic approach than heavily discussed one with App() in
INSTALLED_APPS, i.e., multiple instances of an app is declared as
('foo.polls', 'mayor'). I'd appreciate any comments and feedbacks.

Thanks,


--

Proposal

I'd like to propose a solution which is one of the earlier
recommendations regarding the issue and is simpler among these. App
loading would be defined as follows:

Note: The explanations and illustrations in this proposal will focus
around an application called 'gsoc' – Google Summer of Codes program
classified system which shows the lists of accepted organizations and
ideas of a selected organization. The instances of the app will be
classified systems for this year, last year, and so forth.

INSTALLED_APPS = (

'django.contrib.auth',

'django.contrib.contenttypes',

'django.contrib.sessions',

'django.contrib.sites',

'django.contrib.admin',

'foo.gsoc', #an instance of foo.gsoc; the name is foo.gsoc

('foo.gsoc', '2008'), #an instance of foo.gsoc; the name is foo.gsoc_2008_

('foo.gsoc', '2009'), #an instance of foo.gsoc; the name is foo.gsoc_2009_

)

This way no names would be colliding since it relies on the uniquely
defined full module names (kind of namespace).

The URLconf will be like the following:

urlpatterns = patterns('',

(r'^gsoc/', include('foo.gsoc.urls')),

(r'^gsoc2009/', include('foo.gsoc_2009_.urls')),

(r'^gsoc2008/', include('foo.gsoc_2008_.urls')),

(r'^admin/', include(admin.site.urls)),

)

There's no need to define URLconf for each instance. The URLconf of
each instance is derived from foo/gsoc/urls.py, which in this example
looks like:

from django.conf.urls.defaults import *

import views # notice not absolute. IMPORTANT: Siblings are imported relatively.

urlpatterns = patterns('',

(r'^/', views.index),

(r'^orgs/$', views.list_orgs),

(r'^ideas/(?P\w+)/$', views.list_ideas),

)

In fact, I did work on the Django source trunk in the last couple of
days and made it work. The patch can be found here and my project
here.

The major trick of my work was creating name for an instance and
importing it as module (like followings):

...

for app_name in settings.INSTALLED_APPS:

    if (type(app_name) == types.TupleType):

    a = app_name[0]+ "_" + app_name[1] + "_"

else:

    a = app_name

if a in self.handled:

    continue

...

# in django/db/models/loading.py and some other places

def import_module(name, package=None):

...

    if not name.split('.')[-1].endswith('_'):

  __import__(name)

    else:

  temp_name = name[0:name.rindex('_')]

  new_module = __import__(temp_name[0:temp_name.rindex('_')],
globals(), locals(), ['models'], -1)

   sys.modules[name] = new_module

return sys.modules[name]

# in django/utils/importlib.py



--
Dagvadorj GALBADRAKH

-- 
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: High Level Discussion about the Future of Django

[Russell Keith-Magee]

On Mon, Apr 5, 2010 at 4:04 PM, Jerome Leclanche  wrote:
> The Right Solution for that is officially supporting Python 2.old in
> Django 1.old, and eventually backporting minor features/fixes in
> Django 1.old. The tradeoff here depends on what takes the most
> development time: Backporting features and fixes, or hacking
> compatibility with an old version of the language.

I must be missing something - How exactly does this vary from Django's
current policy?

Django 1.1 supported Python 2.3+ at time of release. It still does.

Django 1.2 will require Python 2.4+. Eventually, we will drop support
for Python 2.4, but Django 1.2 will always support Python 2.4+.

While we're developing Django 1.2, any bugfix is backported to Django
1.1. If that means rewriting or modifying the patch to suit Python
2.3, then that's what we do.

How does this differ from what you call "the Right Solution"?

> With a solid, automatized regression suite;

It's a pity we don't have one of those... oh wait... we do.

> good version/branch
> management (when is Django moving over to git?)

Let's get this straight right now. Moving to git will change *exactly
nothing* in Django's development process. There will *always* be an
"official" repository. Commit access to that core repository will be
limited. It doesn't matter whether that repository is git, svn, or hg
- there will always be a single, canonical, exclusive repository for
trunk.

If you want to use Git to help you manage your own source code or your
contributions to Django, you're welcome to do so. There are well
maintained git mirrors that you can use as a starting point. There are
many people in the Django community using this mirror to manage their
own development work. Allow me to assure you that if you have a git
branch that is worth pulling, someone in the Django core will be able
to pull that branch and merge it into SVN trunk without *any*
difficulty. Multi-db, for instance, was almost entirely developed by
Alex Gaynor on his github branch.

And this is completely independent of the bike shed argument of which
DVCS we will adopt. This isn't even remotely a settled argument. By
making an official move to git, we would alienate a large community
that, for better or worse, can't move their production platforms to
git. It also alienates the hg and bzr communities, which is a not
insignificant consideration (for the record, there are also well
maintained hg and bzr mirrors).

> and a Generally Good
> Codebase, this is never an issue and I don't believe it would be an
> issue with Django.

I'm still not sure what you think the "issue" is. I certainly can't
see how it's related to the original discussion point.

> While I know Django 1.0 is still somewhat supported,

Somewhat? The exact level of support for Django versions is quite well
documented.

Djangp 1.0 is in security support mode. The only thing that will cause
the release or checkin to the 1.0.X branch is the discovery of a
security fault.

Django 1.1 is in support mode. This means that any modification to
trunk that involves a bug fix will be backported to 1.1.

>  focusing efforts
> on such management also enables developers to tackle another issue
> raised earlier here. Upcoming stable releases should NEVER cripple
> development of future features and other changes that won't make such
> a release. Unfortunately, it's what happened in 1.1 and what is
> currently happening.

I presume that you're referring to the regular calls to "wait until
the 1.X development period". There's a world of difference between
saying "Please, can we concentrate on finishing a release", and us
"crippling the development of future features".

Independent development is in no way hampered by this policy. If you
have an itch, you're welcome to scratch it at any time you like.
However, if you expect the core team to volunteer to help you scratch
that itch, then I'm afraid you're going to have a little bit of
consideration for the fact that *your* priorities aren't necessarily
shared by the core team, or by the community as a whole.

We need to put out formal releases. We can't put out formal releases
without killing bugs in features that have been added. We have limited
resources, so for a short period in every development cycle, when
we're trying to get a release out the door, we try to focus on fixing
the problems we already have, rather than working out how to add new
features. If we spend all our resources in the development of new
features, we won't *ever* get a release out the door.

I don't think it's entirely unreasonable that for 2-3 months out of 9,
we ask people to concentrating on fixing what's already been written.
I challenge you to provide any proof that demonstrates that this
policy has "crippled the development of future features".

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 

Re: High Level Discussion about the Future of Django

[Jerome Leclanche]

The Right Solution for that is officially supporting Python 2.old in
Django 1.old, and eventually backporting minor features/fixes in
Django 1.old. The tradeoff here depends on what takes the most
development time: Backporting features and fixes, or hacking
compatibility with an old version of the language.

With a solid, automatized regression suite; good version/branch
management (when is Django moving over to git?) and a Generally Good
Codebase, this is never an issue and I don't believe it would be an
issue with Django.

While I know Django 1.0 is still somewhat supported, focusing efforts
on such management also enables developers to tackle another issue
raised earlier here. Upcoming stable releases should NEVER cripple
development of future features and other changes that won't make such
a release. Unfortunately, it's what happened in 1.1 and what is
currently happening.

J. Leclanche / Adys



On Mon, Apr 5, 2010 at 10:48 AM, Russell Keith-Magee
 wrote:
> On Mon, Apr 5, 2010 at 3:30 PM, Jerome Leclanche  wrote:
>> If you're going to use such an ancient version of a distribution, you
>> are only crippling yourself. As you said yourself, you should move on;
>> if someone is using Python 2.3, they can use Django 1.1/1.2. If they
>> want all-new 1.3 features, then updating Python/distro should not be a
>> roadblock.
>>
>> This is a common issue in software backwards compatibility, and I'm at
>> least one to think that just because someone, somewhere still uses an
>> old version of python, they can't also keep using an old version of
>> Django.
>
> I agree --  to an extent.
>
> I have no problem with the argument that you can't expect to be able
> to walk the leading edge and the trailing edge at the same time.
>
> That said, the problem here is that the users that are most affected
> by backwards incompatibilities and version deprecations are the users
> with the most economic clout - "enterprise" users. For better or
> worse, large organizations have inertia when it comes to adopting core
> infrastructure, and it can be difficult to get this core
> infrastructure updated. However, large organizations also have the
> biggest potential to grow the adoption of a framework like Django and
> move it into the mainstream. This is especially important while we're
> adding features that are of the most interest to enterprise users,
> like multiple database support.
>
> While we don't want to completely hamstring development of Django by
> requiring support for ancient Python versions, we also don't want to
> limit the adoption of Django by large organizations simply by making
> arbitrary demands on core infrastructure, or by breaking backwards
> incompatibility of core features.
>
> It's a fine line we have to walk between being an innovative framework
> and supporting the users that have helped us get to where we are.
>
> 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: High Level Discussion about the Future of Django

[Russell Keith-Magee]

On Mon, Apr 5, 2010 at 3:30 PM, Jerome Leclanche  wrote:
> If you're going to use such an ancient version of a distribution, you
> are only crippling yourself. As you said yourself, you should move on;
> if someone is using Python 2.3, they can use Django 1.1/1.2. If they
> want all-new 1.3 features, then updating Python/distro should not be a
> roadblock.
>
> This is a common issue in software backwards compatibility, and I'm at
> least one to think that just because someone, somewhere still uses an
> old version of python, they can't also keep using an old version of
> Django.

I agree --  to an extent.

I have no problem with the argument that you can't expect to be able
to walk the leading edge and the trailing edge at the same time.

That said, the problem here is that the users that are most affected
by backwards incompatibilities and version deprecations are the users
with the most economic clout - "enterprise" users. For better or
worse, large organizations have inertia when it comes to adopting core
infrastructure, and it can be difficult to get this core
infrastructure updated. However, large organizations also have the
biggest potential to grow the adoption of a framework like Django and
move it into the mainstream. This is especially important while we're
adding features that are of the most interest to enterprise users,
like multiple database support.

While we don't want to completely hamstring development of Django by
requiring support for ancient Python versions, we also don't want to
limit the adoption of Django by large organizations simply by making
arbitrary demands on core infrastructure, or by breaking backwards
incompatibility of core features.

It's a fine line we have to walk between being an innovative framework
and supporting the users that have helped us get to where we are.

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: High Level Discussion about the Future of Django

[Russell Keith-Magee]

On Mon, Apr 5, 2010 at 2:55 PM, Dennis Kaarsemaker
 wrote:
> On ma, 2010-04-05 at 14:37 +0800, Russell Keith-Magee wrote:
>
>> For some perspective - even though Python 3.1 is out, dropping support
>> for Python 2.3 in Django 1.2 is being greeted as controversial in some
>> circles because RedHat Enterprise Linux 5 is still officially
>> supported by RedHat, and RHEL5 ships with Python 2.3.
>
> Rhel 5 ships with 2.4, rhel 4 shipped with 2.3. I still have to use
> django on the latter, so the support for 2.3 being dropped is an issue
> for me. Then again, rhel 4 is positively ancient and I really should
> move on :-)

Sorry - you're completely right - I got my versions confused.

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: High Level Discussion about the Future of Django

[Jerome Leclanche]

If you're going to use such an ancient version of a distribution, you
are only crippling yourself. As you said yourself, you should move on;
if someone is using Python 2.3, they can use Django 1.1/1.2. If they
want all-new 1.3 features, then updating Python/distro should not be a
roadblock.

This is a common issue in software backwards compatibility, and I'm at
least one to think that just because someone, somewhere still uses an
old version of python, they can't also keep using an old version of
Django.


J. Leclanche / Adys



On Mon, Apr 5, 2010 at 9:55 AM, Dennis Kaarsemaker
 wrote:
> On ma, 2010-04-05 at 14:37 +0800, Russell Keith-Magee wrote:
>
>> For some perspective - even though Python 3.1 is out, dropping support
>> for Python 2.3 in Django 1.2 is being greeted as controversial in some
>> circles because RedHat Enterprise Linux 5 is still officially
>> supported by RedHat, and RHEL5 ships with Python 2.3.
>
> Rhel 5 ships with 2.4, rhel 4 shipped with 2.3. I still have to use
> django on the latter, so the support for 2.3 being dropped is an issue
> for me. Then again, rhel 4 is positively ancient and I really should
> move on :-)
>
> --
> Dennis K.
>
> They've gone to plaid!
>
> --
> 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: High Level Discussion about the Future of Django

[Dennis Kaarsemaker]

On ma, 2010-04-05 at 14:37 +0800, Russell Keith-Magee wrote:

> For some perspective - even though Python 3.1 is out, dropping support
> for Python 2.3 in Django 1.2 is being greeted as controversial in some
> circles because RedHat Enterprise Linux 5 is still officially
> supported by RedHat, and RHEL5 ships with Python 2.3.

Rhel 5 ships with 2.4, rhel 4 shipped with 2.3. I still have to use
django on the latter, so the support for 2.3 being dropped is an issue
for me. Then again, rhel 4 is positively ancient and I really should
move on :-)

-- 
Dennis K.

They've gone to plaid!

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