Re: A prompt 1.2.3 release

[Paul McMillan]

> Unfortunately we didn't catch this failure in four weeks, the fact
> that the buildbot
> isn't running tests for the 1.2.X branch doeesn't help either.

The buildbot actually is running the 1.2.x tests, it is just
unfortunately named (and apparently re-naming it is a bit of a pain so
it hasn't happened yet). Look at the actual logs of any given build to
see what's actually checked out.

-Paul

-- 
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: About the django-core mailing list

[Anton Bessonov]

I would say that any information on why a structure exists is good.
  


There is no difference have developers a confidential list, a chat or 
they communicate by phone, right? It has no relation to structure. It is 
a natural way for the decision not public problems.


--
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: About the django-core mailing list

[Jerome Leclanche]

On Fri, Sep 10, 2010 at 1:17 AM, Anton Bessonov  wrote:
>
>> I disagree. Although it is normal for a project to have private
>> mailing lists, such as -security
>
> You disagree, but it is normal? Decide for you first.

I disagree that there was no explanation necessary. As Graham very
elegantly put it up, any information on why a structure exists is
good.

>>
>> I'm very glad Jacob took the time to
>> explain the need for its presence in Django.
>
> There is a difference about knowledge of the confidential list, trac, repo?
> Even for OpenSource there is one thousand reasons to have the private list.

I have no idea what you are getting at.

J. Leclanche

>
> --
> 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: About the django-core mailing list

[Anton Bessonov]

I disagree. Although it is normal for a project to have private
mailing lists, such as -security

You disagree, but it is normal? Decide for you first.

I'm very glad Jacob took the time to
explain the need for its presence in Django.
There is a difference about knowledge of the confidential list, trac, 
repo? Even for OpenSource there is one thousand reasons to have the 
private list.


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

A prompt 1.2.3 release

[Luke Plant]

Hi all,

It looks like we'll be needing a fairly prompt 1.2.3 release.  So far
we've got:

One major/critical bug (depending on how many people are using the
deprecated CsrfResponseMiddleware):

http://code.djangoproject.com/ticket/14235

One significant regression:

http://code.djangoproject.com/ticket/14242

Packaging error(s):

http://code.djangoproject.com/ticket/14245

Many core devs are at Djangocon and are just starting sprints, I'm not
sure whether that will help or hinder.

Luke

-- 
A common mistake that people make when trying to design something 
completely foolproof is to underestimate the ingenuity of complete 
fools.  -- Douglas Adams

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: #9459 forms.DateTimeField() looses microseconds

[Tobias McNulty]

On Thu, Sep 9, 2010 at 5:43 AM, Thomas Guettler  wrote:

> Here is the patch:
>
> http://code.djangoproject.com/attachment/ticket/9459/datetime-microseconds-py25.patch
>
> If the python version is greater-equal than 2.6, it uses %f to parse the
> microseconds,
> for older versions it parses the last integer itself.
>

The patch looks reasonable enough to me and I'm excited about getting it in.
 Have you tested it on Python 2.4, 2.5, and 2.6?

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: parameterized apps (was: Re: Eric Florenzano's presentation slides)

[Arthur Koziel]

On Sep 9, 2010, at 7:24 AM, Javier Guerra Giraldez wrote:

> what about giving parameters to the apps?  something like:
> 
> INSTALLED_APPS = (
>   'django.contrib.auth',
>   'django.contrib.contenttypes',
>   'django.contrib.sessions',
>   'django.contrib.sites',
>   'django.contrib.admin',
>   ('debug_toolbar', {
>   'INTERCEPT_REDIRECTS': False,
>   'INTERNAL_IPS': ('127.0.0.2',),
>   }),
>   'django_extensions',
>   ('favorites', {
>   'fave': ‘pages.models.Page',
>   }),
>   'comercial',
>   'specs',
> )

Hey Javier,

this approach has been discussed in my GSOC proposal thread[0]. In the end, we 
decided to leave INSTALLED_APPS as strings to maintain backwards compatibility. 
There are also some other resources which you can find on the wiki[1]. You can 
read through my final status report if you're interested in how the gsoc 
went[2]. I'm currently at DjangoCon and we're going to use the sprints to look 
into how the app-loading branch can be integrated into trunk.

Arthur

[0]: 
http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879/0cee4bc0557aa9cc
[1]: http://code.djangoproject.com/wiki/SummerOfCode2010#Apploading
[2]: 
http://groups.google.com/group/django-developers/browse_thread/thread/3d730dd8b6653dbb/cd6ce11986aeb162

-- 
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: About the django-core mailing list

[Graham Dumpleton]

On Sep 10, 8:41 am, Anton Bessonov  wrote:
> +1. Explaining existence of private  core-list is needless.

I would say that any information on why a structure exists is good.

The Apache Software Foundation would be a good example of where a lot
of effort has been taken to explain how things work. The result is
that even though there are closed groups within that structure, people
at least know they exist, why they exist, why they are closed and what
they do. Most will not read this stuff, but for those who fuss over
such things, all the information is there.

  http://www.apache.org/foundation/how-it-works.html#structure

As a possible analogue to this core developers list, in the ASF you
have various project management committees. These PMCs have closed
mailing lists for discussion, albeit mainly for administrative
matters. The scope of what these do is also described.

  http://www.apache.org/dev/pmc.html

Graham

> But also +1 for other points in Eric's presentation.
>
>
>
> > Thanks Jacob,
>
> > I don't understand why we are discussing about it.
> > It's quite obvious that if there is a core team, there's also a
> > mailing list.
>
> > S

-- 
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: Proposal: extending the storage backend api

[Stephan Jäkel]

I forgot to mention the ticket for the "stat" method:
http://code.djangoproject.com/ticket/10497

Stephan Jäkel wrote:

FYI, there is a ticket in trac which recommends to add a "stat" method
but I think this maybe would be hard to implement on backends like S3.


Cheers,

--
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: About the django-core mailing list

[Richard Laager]

On Thu, 2010-09-09 at 12:30 -0500, Jacob Kaplan-Moss wrote:
> 1. Security-related issues. When we receive a security report, we need
> to discuss it in private.

Just as a data point...
I'm a committer on a widely-used open source application, and we discuss
these things on a "packagers" list. As the name suggests, this list
includes the package maintainers for various distros. I think they find
this very useful and I know we find their input helpful.

Richard


signature.asc
Description: This is a digitally signed message part

Re: About the django-core mailing list

[Jerome Leclanche]

I disagree. Although it is normal for a project to have private
mailing lists, such as -security, I'm very glad Jacob took the time to
explain the need for its presence in Django. And a big +1 on
scheduling releases in public.


J. Leclanche



On Thu, Sep 9, 2010 at 11:41 PM, Anton Bessonov  wrote:
> +1. Explaining existence of private  core-list is needless.
>
> But also +1 for other points in Eric's presentation.
>
>
>> Thanks Jacob,
>>
>> I don't understand why we are discussing about it.
>> It's quite obvious that if there is a core team, there's also a mailing
>> list.
>>
>> S
>
> --
> 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: parameterized apps (was: Re: Eric Florenzano's presentation slides)

[Russell Keith-Magee]

On Fri, Sep 10, 2010 at 6:42 AM, Javier Guerra Giraldez
 wrote:
> On Thu, Sep 9, 2010 at 4:02 PM, Alex Gaynor  wrote:
>> So how does this work?  Where do args come from?
>
> args (for lack of a better name) is the same dictionary passed as the
> second part of the tuple in the INSTALLED_APPS list.
>
> when Django loads each app, if the entry in INSTALLED_APPS is a tuple,
> the first member is the app name, and the second one is made available
> to the app as 'args'.

Yes - but you're glossing over the important part. You say args is
"made available" - how? Based on your example:

>  class Favorite(models.Model):
>      item = ForeignKey(args[‘fave’])

args must be in the global namespace, which means you have to have:

from somewhere import args

before your model definition. What is the 'somewhere'?

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: parameterized apps (was: Re: Eric Florenzano's presentation slides)

[Javier Guerra Giraldez]

On Thu, Sep 9, 2010 at 4:02 PM, Alex Gaynor  wrote:
>>> INSTALLED_APPS = (
>>>        'django.contrib.auth',
>>>        'django.contrib.contenttypes',
>>>        'django.contrib.sessions',
>>>        'django.contrib.sites',
>>>        'django.contrib.admin',
>>>        ('debug_toolbar', {
>>>                'INTERCEPT_REDIRECTS': False,
>>>                'INTERNAL_IPS': ('127.0.0.2',),
>>>        }),
>>>        'django_extensions',
>>>        ('favorites', {
>>>                'fave': ‘pages.models.Page',
>>>        }),
>>>        'comercial',
>>>        'specs',
>>> )
>>>
>>>
>>> and in favorites.models.py:
>>>
>>>  class Favorite(models.Model):
>>>      item = LazyForeignKey(args[‘fave’])
>>>      user = ForeignKey(User)
>>>      date = DateTimeField(default=utcnow)
>>>
>
> So how does this work?  Where do args come from?

args (for lack of a better name) is the same dictionary passed as the
second part of the tuple in the INSTALLED_APPS list.

when Django loads each app, if the entry in INSTALLED_APPS is a tuple,
the first member is the app name, and the second one is made available
to the app as 'args'.


((erratum: in this case, we don't need any 'LazyForeignKey', the usual
'ForeignKey' works:

  class Favorite(models.Model):
  item = ForeignKey(args[‘fave’])
  user = ForeignKey(User)
  date = DateTimeField(default=utcnow)

))


-- 
Javier

-- 
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: About the django-core mailing list

[Anton Bessonov]

+1. Explaining existence of private  core-list is needless.

But also +1 for other points in Eric's presentation.



Thanks Jacob,

I don't understand why we are discussing about it.
It's quite obvious that if there is a core team, there's also a 
mailing list.


S


--
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: parameterized apps (was: Re: Eric Florenzano's presentation slides)

[Javier Guerra Giraldez]

On Thu, Sep 9, 2010 at 3:59 PM, Russell Keith-Magee
 wrote:

> What you're proposing here is two things: a LazyForeignKey, and
> configurable applications.

not really, it's only configurable applications.  once you have that,
it's easy to make the ForeignKey depend on a parameter.

> Configurable apps were the subject of Arthur Koziel's GSoC project
> this year. From my conversations with Jannis this week at DjangoCon,
> it sounds like this GSoC code is in pretty good shape. However, in
> order to smooth the path, we will probably end up landing some
> preliminary work for 1.3, and land the final patch for 1.4.

yes, i've just seen the link posted by Yuri.  maybe GSoC projects
could use some more visiblity, a Git fork of the whole Django code
doesn't make it easy to know what's happening there.

judging just from the GSoC proposal, an app object could make a lot of
OOP goodness available.

> The LazyForeignKey pattern has been proposed by a number of parties;
> it's an interesting idea that is worth some serious consideration.
> There are some issues with implementation (e.g., exactly how to
> describe the relationship in a clean way that doesn't require us to
> import settings in order to define models), but these issues shouldn't
> be too hard to sort out. I'll see if I can get some discussion going
> at the sprints over the next couple of days.

it all that really necessary? i'd think that just not using hardcoded
constants for the model class or name buys a _lot_ of flexibility.

of course, that's easily doable right now.  the simplest case would be
just using settings variables:

in settings.py:

  FAVORITES_FAVE_MODEL=‘pages.models.Page'

in favorites/models.py:

  class Favorite(models.Model):
  item = ForeignKey(settings.FAVORITES_FAVE_MODEL)
  user = ForeignKey(User)
  date = DateTimeField(default=utcnow)


but that's just ugly, and pollutes a global namespace.  hence,
configurable apps :-)


-- 
Javier

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

Proposal: extending the storage backend api

[Stephan Jäkel]

Hi,

this proposal is about extending the storage backend api of Django.

The storage backend has already many helpful methods to get information 
about stored files like:

- name
- size
- full path (for some backends).

I think it could be useful to have some more methods to get information 
about times:

- accessed time
- created time
- modified time

By adding this methods, Django's storage backend would provide a 
standardized way to get the times.


The default implementation could go the same way as "path",
class Storage:
 def path(self, name):
  raise NotImplementedError("This backend doesn't support absolute paths.")

If a storage backend implement one of the new methods "accessed_time", 
"modified_time" or "created_time", the backend has to return a Datetime object.


I would implement this for the included storage backends, write tests and 
docs at the sprints in Portland.


FYI, there is a ticket in trac which recommends to add a "stat" method but I 
think this maybe would be hard to implement on backends like S3.


By splitting the times up in three methods, backend providers can decide 
which data they provide.


This is a fairly short proposal but I think its not a big change and just 
adds some conventions to the storage backend api.


Looking forward to your feedback!

Cheers,

Steph

--
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: parameterized apps (was: Re: Eric Florenzano's presentation slides)

[Patryk Zawadzki]

On Thu, Sep 9, 2010 at 10:59 PM, Russell Keith-Magee
 wrote:
> The LazyForeignKey pattern has been proposed by a number of parties;
> it's an interesting idea that is worth some serious consideration.
> There are some issues with implementation (e.g., exactly how to
> describe the relationship in a clean way that doesn't require us to
> import settings in order to define models), but these issues shouldn't
> be too hard to sort out. I'll see if I can get some discussion going
> at the sprints over the next couple of days.

See the blog link I posted, there I propose a factory pattern that
allows you to (1) extend the base factory class (2) use the factory to
create the actual Django model in your own app, passing any missing
bits the factory might be expecting.

It solves the "lazy binding" case and also lets you create more than
one model with the same structure and functionality attached.

As for views I recommend something along the lines of:

url(r'^bar/', include('fooapp.urls'), {'model': Bar}),
url(r'^baz/', include('fooapp.urls'), {'model': Baz}),

-- 
Patryk Zawadzki

-- 
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: parameterized apps (was: Re: Eric Florenzano's presentation slides)

[Alex Gaynor]

On Thu, Sep 9, 2010 at 1:59 PM, Russell Keith-Magee
 wrote:
> On Thu, Sep 9, 2010 at 10:24 PM, Javier Guerra Giraldez
>  wrote:
>> from Eric Florenzano's slide 41:
>>
>>  In models.py:
>>
>>  class Favorite(models.Model):
>>      item = LazyForeignKey(‘fave’)
>>      user = ForeignKey(User)
>>      date = DateTimeField(default=utcnow)
>>
>>
>>  In settings.py:
>>
>>  LAZY_FKS = {‘fave’: ‘pages.models.Page’}
>>
>>
>> I share the dislike for generic relationships; but don't think this
>> solution is particularly elegant, nor flexible enough.
>>
>> what about giving parameters to the apps?  something like:
>>
>> INSTALLED_APPS = (
>>        'django.contrib.auth',
>>        'django.contrib.contenttypes',
>>        'django.contrib.sessions',
>>        'django.contrib.sites',
>>        'django.contrib.admin',
>>        ('debug_toolbar', {
>>                'INTERCEPT_REDIRECTS': False,
>>                'INTERNAL_IPS': ('127.0.0.2',),
>>        }),
>>        'django_extensions',
>>        ('favorites', {
>>                'fave': ‘pages.models.Page',
>>        }),
>>        'comercial',
>>        'specs',
>> )
>>
>>
>> and in favorites.models.py:
>>
>>  class Favorite(models.Model):
>>      item = LazyForeignKey(args[‘fave’])
>>      user = ForeignKey(User)
>>      date = DateTimeField(default=utcnow)
>>

So how does this work?  Where do args come from?

>>
>> this helps to reduce global settings pollution, simply by binding a
>> global ('args' in this example) to the respective app's parameter
>> dictionary.
>>
>> it could even allow a project to import a single app twice with
>> different parameters:
>>
>> INSTALLED_APPS = (
>>        ...
>>        ('favoritebooks', {
>>                'APP_MODULE': 'favorites',
>>                'fave': ‘pages.models.Book',
>>        }),
>>        ('favoritepages', {
>>                'APP_MODULE': 'favorites',
>>                'fave': ‘pages.models.Page',
>>        }),
>>        'comercial',
>>        'specs',
>> )
>>
>> here, APP_MODULE tells Django where to import the app from, by default
>> it would be the app name (as now), but specifying it separately allows
>> the user to give a different name to the app in the project's context.
>>
>> toughts?
>
> What you're proposing here is two things: a LazyForeignKey, and
> configurable applications.
>
> Configurable apps were the subject of Arthur Koziel's GSoC project
> this year. From my conversations with Jannis this week at DjangoCon,
> it sounds like this GSoC code is in pretty good shape. However, in
> order to smooth the path, we will probably end up landing some
> preliminary work for 1.3, and land the final patch for 1.4.
>
> The LazyForeignKey pattern has been proposed by a number of parties;
> it's an interesting idea that is worth some serious consideration.
> There are some issues with implementation (e.g., exactly how to
> describe the relationship in a clean way that doesn't require us to
> import settings in order to define models), but these issues shouldn't
> be too hard to sort out. I'll see if I can get some discussion going
> at the sprints over the next couple of days.
>
> 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.
>
>

Personally I think LazyForeignKey is a bad pattern, that being said
it's totally possible to implement right now, there is nothing needed
in Django core.

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: parameterized apps (was: Re: Eric Florenzano's presentation slides)

[Russell Keith-Magee]

On Thu, Sep 9, 2010 at 10:24 PM, Javier Guerra Giraldez
 wrote:
> from Eric Florenzano's slide 41:
>
>  In models.py:
>
>  class Favorite(models.Model):
>      item = LazyForeignKey(‘fave’)
>      user = ForeignKey(User)
>      date = DateTimeField(default=utcnow)
>
>
>  In settings.py:
>
>  LAZY_FKS = {‘fave’: ‘pages.models.Page’}
>
>
> I share the dislike for generic relationships; but don't think this
> solution is particularly elegant, nor flexible enough.
>
> what about giving parameters to the apps?  something like:
>
> INSTALLED_APPS = (
>        'django.contrib.auth',
>        'django.contrib.contenttypes',
>        'django.contrib.sessions',
>        'django.contrib.sites',
>        'django.contrib.admin',
>        ('debug_toolbar', {
>                'INTERCEPT_REDIRECTS': False,
>                'INTERNAL_IPS': ('127.0.0.2',),
>        }),
>        'django_extensions',
>        ('favorites', {
>                'fave': ‘pages.models.Page',
>        }),
>        'comercial',
>        'specs',
> )
>
>
> and in favorites.models.py:
>
>  class Favorite(models.Model):
>      item = LazyForeignKey(args[‘fave’])
>      user = ForeignKey(User)
>      date = DateTimeField(default=utcnow)
>
>
> this helps to reduce global settings pollution, simply by binding a
> global ('args' in this example) to the respective app's parameter
> dictionary.
>
> it could even allow a project to import a single app twice with
> different parameters:
>
> INSTALLED_APPS = (
>        ...
>        ('favoritebooks', {
>                'APP_MODULE': 'favorites',
>                'fave': ‘pages.models.Book',
>        }),
>        ('favoritepages', {
>                'APP_MODULE': 'favorites',
>                'fave': ‘pages.models.Page',
>        }),
>        'comercial',
>        'specs',
> )
>
> here, APP_MODULE tells Django where to import the app from, by default
> it would be the app name (as now), but specifying it separately allows
> the user to give a different name to the app in the project's context.
>
> toughts?

What you're proposing here is two things: a LazyForeignKey, and
configurable applications.

Configurable apps were the subject of Arthur Koziel's GSoC project
this year. From my conversations with Jannis this week at DjangoCon,
it sounds like this GSoC code is in pretty good shape. However, in
order to smooth the path, we will probably end up landing some
preliminary work for 1.3, and land the final patch for 1.4.

The LazyForeignKey pattern has been proposed by a number of parties;
it's an interesting idea that is worth some serious consideration.
There are some issues with implementation (e.g., exactly how to
describe the relationship in a clean way that doesn't require us to
import settings in order to define models), but these issues shouldn't
be too hard to sort out. I'll see if I can get some discussion going
at the sprints over the next couple of days.

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.

hello .L

[Steven Davidson]

hello  friends:
I have good news for you. Last week ,I have Order china 7
Products
w e b:  www.hoaoeso1.com   I have received the product!
It's amazing! The item is original, brand new and has high quality,
but it's muc cheaper. I'm pleased to share this good news with you!
I believe you will find what you want there and have an good experience
on shopping from them.
Regards!







A

-- 
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: About the django-core mailing list

[Simone Federici]

 Thanks Jacob,

I don't understand why we are discussing about it.
It's quite obvious that if there is a core team, there's also a mailing
list.

S


On Thu, Sep 9, 2010 at 19:30, Jacob Kaplan-Moss  wrote:

> Hi folks --
>
> A bit of context before I dive in: at DjangoCon, Eric Florenzano gave
> a "what's broken about Django" talk. I sadly had to miss DjangoCon,
> and so I'm anxiously waiting to see the video, but I did see one thing
> in the slides I thought I should address right away. Actually, this is
> something we should have made clearer *long* ago, but better late than
> never, I suppose.
>
> So yes, there is a "django-core" mailing list, which is private and
> by-invitiation-only. Only committers have access to this list and to
> its archives. This smacks of insularism, and sounds exclusionary, and
> in general is a pretty bad "symbol" to our community. If we're an open
> community, and if we accept contributions from anyone, why the heck
> does this list exist?
>
> For a *long* time we tried to avoid having any such private list on
> the theory that we should try to be as open as possible. I resisted
> creating the list for as long as possible, and I'm still somewhat
> unhappy that it's a necessity. Now that it's there, we try to use it
> as little as possible
>
> However, at a certain point we finally realized that we *did* need a
> place to discuss issues too sensitive for public discourse. Those
> things are:
>
> 1. Security-related issues. When we receive a security report, we need
> to discuss it in private. As soon as an issue is made public we're
> entered into a race against malicious script kiddies, so we need some
> place to discuss and resolve security issues and then coordinate
> issuing fixes outside of public scrutiny. This is, as far as I know,
> considered to be a general best practice for open source projects. Our
> security policy is detailed at
>
> http://docs.djangoproject.com/en/1.2/internals/contributing/#reporting-security-issues
> ,
> and as always we're open to suggestions if folks think we're doing it
> wrong.
>
> 2. Commit access. As everyone knows, we've got very high standards.
> This means that when someone's nominated for commit access we want
> have a frank, no-holds-barred discussion of that person's skills. This
> discussion is a lot like the hire/no-hire discussion that an interview
> team might have after talking to a candidate, which means that we
> might say something about a candidate's ability that isn't so nice.
> It's not fair to the candidate to have his or her merits and demerits
> discussed publicly, and we feel we need to freedom that privacy brings
> if we're going to be honest.
>
> Those were the two reasons that led us to create the list. This list
> is used infrequently -- there have been about 670 messages since it
> was started in 2007 -- and the above two topics dominate the archives.
> However, looking over the archives there *are* a few other types of
> threads we've had:
>
> 3. Procedural complaints, screeds, or intra-personal problems.
> Sometimes we need a venue to vent to other core developers. There've
> been a few threads on this list of the years that, quite simply, would
> have been taken completely out of context if posted publicly. We all
> know each other very well, and so if I post a major rant on
> django-core everyone else there knows me well enough to take it in
> context, extract the constructive aspects, and ignore the rest. If
> this rant was posted publically we'd have all sorts of "OMG Django
> Lead Developer Disses Project!!!111eleven" posts on Reddit and such.
> Good times.
>
> If not for django-core these would be posted over private email or
> simply left unsaid, so I'm okay with continuing to use a private list
> for... well... private things!
>
> 4. Coordination -- release dates, timelines, etc. We've also used
> django-core to discuss release schedules and other process
> coordination.
>
> In retrospect, I'm *not* comfortable with the use of django-core for
> stuff like this. I suspect we've used the private list to prevent the
> type of bikeshedding that usually happens when trivial things like
> release dates and timelines come up, but that's a bad reason. I'm no
> longer going to use a private list for this stuff, and I'm going to
> encourage others to stop.
>
> * * *
>
> I hope this clears up why we (think we) require a private list, and I
> hope it makes the activities on that list transparent enough. If
> anyone has any questions or concerns -- now or any time -- about this
> list or any other private communication among the core team, please
> feel free to bring those concerns up -- here, or to me in private
> email, or wherever.
>
> The goal is to only be private when we absolutely *must*, and if we're
> not sufficiently transparent *please* say something.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post 

Re: About the django-core mailing list

[Dennis Kaarsemaker]

On do, 2010-09-09 at 12:30 -0500, Jacob Kaplan-Moss wrote:

> The goal is to only be private when we absolutely *must*, and if we're
> not sufficiently transparent *please* say something. 

Thanks Jacob, for explaining this.

This makes a good amount of sense, and Django is not unique here. I am
involved with other high-profile open source projects where similar
'core' lists exist for the very same reasons, except for the
coordination bits, which you already addressed as possibly being a bad
topic for a private list. It works very well for these projects and I am
convinced it works well for any project, if used responsibly.

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

About the django-core mailing list

[Jacob Kaplan-Moss]

Hi folks --

A bit of context before I dive in: at DjangoCon, Eric Florenzano gave
a "what's broken about Django" talk. I sadly had to miss DjangoCon,
and so I'm anxiously waiting to see the video, but I did see one thing
in the slides I thought I should address right away. Actually, this is
something we should have made clearer *long* ago, but better late than
never, I suppose.

So yes, there is a "django-core" mailing list, which is private and
by-invitiation-only. Only committers have access to this list and to
its archives. This smacks of insularism, and sounds exclusionary, and
in general is a pretty bad "symbol" to our community. If we're an open
community, and if we accept contributions from anyone, why the heck
does this list exist?

For a *long* time we tried to avoid having any such private list on
the theory that we should try to be as open as possible. I resisted
creating the list for as long as possible, and I'm still somewhat
unhappy that it's a necessity. Now that it's there, we try to use it
as little as possible

However, at a certain point we finally realized that we *did* need a
place to discuss issues too sensitive for public discourse. Those
things are:

1. Security-related issues. When we receive a security report, we need
to discuss it in private. As soon as an issue is made public we're
entered into a race against malicious script kiddies, so we need some
place to discuss and resolve security issues and then coordinate
issuing fixes outside of public scrutiny. This is, as far as I know,
considered to be a general best practice for open source projects. Our
security policy is detailed at
http://docs.djangoproject.com/en/1.2/internals/contributing/#reporting-security-issues,
and as always we're open to suggestions if folks think we're doing it
wrong.

2. Commit access. As everyone knows, we've got very high standards.
This means that when someone's nominated for commit access we want
have a frank, no-holds-barred discussion of that person's skills. This
discussion is a lot like the hire/no-hire discussion that an interview
team might have after talking to a candidate, which means that we
might say something about a candidate's ability that isn't so nice.
It's not fair to the candidate to have his or her merits and demerits
discussed publicly, and we feel we need to freedom that privacy brings
if we're going to be honest.

Those were the two reasons that led us to create the list. This list
is used infrequently -- there have been about 670 messages since it
was started in 2007 -- and the above two topics dominate the archives.
However, looking over the archives there *are* a few other types of
threads we've had:

3. Procedural complaints, screeds, or intra-personal problems.
Sometimes we need a venue to vent to other core developers. There've
been a few threads on this list of the years that, quite simply, would
have been taken completely out of context if posted publicly. We all
know each other very well, and so if I post a major rant on
django-core everyone else there knows me well enough to take it in
context, extract the constructive aspects, and ignore the rest. If
this rant was posted publically we'd have all sorts of "OMG Django
Lead Developer Disses Project!!!111eleven" posts on Reddit and such.
Good times.

If not for django-core these would be posted over private email or
simply left unsaid, so I'm okay with continuing to use a private list
for... well... private things!

4. Coordination -- release dates, timelines, etc. We've also used
django-core to discuss release schedules and other process
coordination.

In retrospect, I'm *not* comfortable with the use of django-core for
stuff like this. I suspect we've used the private list to prevent the
type of bikeshedding that usually happens when trivial things like
release dates and timelines come up, but that's a bad reason. I'm no
longer going to use a private list for this stuff, and I'm going to
encourage others to stop.

* * *

I hope this clears up why we (think we) require a private list, and I
hope it makes the activities on that list transparent enough. If
anyone has any questions or concerns -- now or any time -- about this
list or any other private communication among the core team, please
feel free to bring those concerns up -- here, or to me in private
email, or wherever.

The goal is to only be private when we absolutely *must*, and if we're
not sufficiently transparent *please* say something.

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: parameterized apps (was: Re: Eric Florenzano's presentation slides)

[burc...@gmail.com]

Hi Javier,

after GSoC 2010, we have
http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/django/t127230758002
feature at 
http://code.djangoproject.com/browser/django/branches/soc2010/app-loading

Not that good syntax, but this solution can help you!

P.S. The more testers we have, the faster the branch will be
integrated into the trunk!

On Thu, Sep 9, 2010 at 9:24 PM, Javier Guerra Giraldez
 wrote:
> from Eric Florenzano's slide 41:
>
>  In models.py:
>
>  class Favorite(models.Model):
>      item = LazyForeignKey(‘fave’)
>      user = ForeignKey(User)
>      date = DateTimeField(default=utcnow)
>
>
>  In settings.py:
>
>  LAZY_FKS = {‘fave’: ‘pages.models.Page’}
>
>
> I share the dislike for generic relationships; but don't think this
> solution is particularly elegant, nor flexible enough.
>
> what about giving parameters to the apps?  something like:
>
> INSTALLED_APPS = (
>        'django.contrib.auth',
>        'django.contrib.contenttypes',
>        'django.contrib.sessions',
>        'django.contrib.sites',
>        'django.contrib.admin',
>        ('debug_toolbar', {
>                'INTERCEPT_REDIRECTS': False,
>                'INTERNAL_IPS': ('127.0.0.2',),
>        }),
>        'django_extensions',
>        ('favorites', {
>                'fave': ‘pages.models.Page',
>        }),
>        'comercial',
>        'specs',
> )
>
>
> and in favorites.models.py:
>
>  class Favorite(models.Model):
>      item = LazyForeignKey(args[‘fave’])
>      user = ForeignKey(User)
>      date = DateTimeField(default=utcnow)
>
>
> this helps to reduce global settings pollution, simply by binding a
> global ('args' in this example) to the respective app's parameter
> dictionary.
>
> it could even allow a project to import a single app twice with
> different parameters:
>
> INSTALLED_APPS = (
>        ...
>        ('favoritebooks', {
>                'APP_MODULE': 'favorites',
>                'fave': ‘pages.models.Book',
>        }),
>        ('favoritepages', {
>                'APP_MODULE': 'favorites',
>                'fave': ‘pages.models.Page',
>        }),
>        'comercial',
>        'specs',
> )
>
> here, APP_MODULE tells Django where to import the app from, by default
> it would be the app name (as now), but specifying it separately allows
> the user to give a different name to the app in the project's context.
>
> toughts?
>
> --
> Javier
>
> --
> 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.
>
>



-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

-- 
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: parameterized apps (was: Re: Eric Florenzano's presentation slides)

[Patryk Zawadzki]

On Thu, Sep 9, 2010 at 4:24 PM, Javier Guerra Giraldez
 wrote:
> from Eric Florenzano's slide 41:
> (...)

You might want to take a look at my little sandbox here:

http://room-303.com/blog/2010/04/27/django-abstrakcji-ciag-dalszy/

(Sorry the post is in Polish but the only interesting part is the code)

-- 
Patryk Zawadzki

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

parameterized apps (was: Re: Eric Florenzano's presentation slides)

[Javier Guerra Giraldez]

from Eric Florenzano's slide 41:

  In models.py:

  class Favorite(models.Model):
  item = LazyForeignKey(‘fave’)
  user = ForeignKey(User)
  date = DateTimeField(default=utcnow)


  In settings.py:

  LAZY_FKS = {‘fave’: ‘pages.models.Page’}


I share the dislike for generic relationships; but don't think this
solution is particularly elegant, nor flexible enough.

what about giving parameters to the apps?  something like:

INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.admin',
('debug_toolbar', {
'INTERCEPT_REDIRECTS': False,
'INTERNAL_IPS': ('127.0.0.2',),
}),
'django_extensions',
('favorites', {
'fave': ‘pages.models.Page',
}),
'comercial',
'specs',
)


and in favorites.models.py:

  class Favorite(models.Model):
  item = LazyForeignKey(args[‘fave’])
  user = ForeignKey(User)
  date = DateTimeField(default=utcnow)


this helps to reduce global settings pollution, simply by binding a
global ('args' in this example) to the respective app's parameter
dictionary.

it could even allow a project to import a single app twice with
different parameters:

INSTALLED_APPS = (
...
('favoritebooks', {
'APP_MODULE': 'favorites',
'fave': ‘pages.models.Book',
}),
('favoritepages', {
'APP_MODULE': 'favorites',
'fave': ‘pages.models.Page',
}),
'comercial',
'specs',
)

here, APP_MODULE tells Django where to import the app from, by default
it would be the app name (as now), but specifying it separately allows
the user to give a different name to the app in the project's context.

toughts?

-- 
Javier

-- 
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: CSRF Middleware/SSL/Firefox 3.6.8 bug

[David De La Harpe Golden]

On 08/09/10 09:22, Patryk Zawadzki wrote:

>> 1) Use of IP address - a bad idea for the reasons I mentioned in my
>> other message.
> 
> A lot of web frameworks I've worked with use the IP to lock the
> session cookie to prevent easy cookie theft.

... just mentioning the existence of django-paranoid-sessions which
will do request header fingerprinting among other things.

http://github.com/rfk/django-paranoid-sessions
http://www.rfk.id.au/blog/entry/announcing-django-paranoid-sessions

-- 
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: Error email flooding on high traffic production sites

[Russell Keith-Magee]

On Thu, Sep 9, 2010 at 11:26 AM, Simon Litchfield  wrote:
> Hi all
>
> Default behaviour of sending an email on 500 error is great.
>
> Problem is on high traffic sites, and you might just be making a quick
> update- literally within seconds you can bring your mail server down-
> crash your mail client- or render your gmail account useless.
>
> With "batteries included" and "production ready" ethos in mind, I
> reckon this needs fixing.
>
> 1) Max emails per minute setting
>
> 2) Include alternative error handler middleware in core
>
> I haven't tried it yet, but this looks interesting (note web2py
> includes this) --
> http://bitbucket.org/ashcrow/django-error-capture-middleware/wiki/Home
>
> Thoughts? I know I'm not the only one who has run into this (Russ?)

This exact problem is the reason why adding logging support is on my
todo list for 1.3. Essentially, the idea is that by merging Vinay's
logging work, the current behavior of 'send an email on server error'
can become a configuration item; the default configuration would be to
send an email (for backwards compatibility), but this setting could be
easily modified to be 'write to a file', 'write to syslog', 'post to
Arecibo', 'write to database', or any other logging handler you care
to write and install -- potentially multiple handlers, if required.

If you want to keep email error handling but want to avoid the
problems you describe, you can then write (and install) a custom error
logging handler that has the properties you describe.

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.