Re: Odd behavior on proxy models should be on documentation

[Alex Ogier]

This looks exactly as I expect. Proxy models are not distinct in the
database from their parent models, they are just python wrappers around
them. It is documented and expected that creating instances of the parent
class creates instances of the proxy class. Since creating an instance of a
concrete subclass creates a parent model instance as well (you can see two
Generic instances when you print the Generic queryset) it should be no
surprise that you see two Specific instances -- they represent the same
data!

It is also expected behavior that you will never see Specific instances
unless you access the underlying data through Specific's manager.
InheritanceManager is doing a little magic to show you SpecificA instances,
but its behavior shouldn't be surprising. The Generic instance created by
SpecificA has a one-to-one join in the database giving it an unambiguous
representation as a SpecificA instance instead of Generic. Proxy models
don't have any representation at all in the database, so how is
InheritanceManager to know that Generic isn't the canonical representation?
As a thought experiment, consider if there were several different proxy
subclasses of Generic, how would you be able to choose which subclass to
show when there's no indication in the data?

I don't think anything strange is going on here, and the documentation is
adequate, though of course not perfect. Concrete subclasses create rows for
their parent class. Proxy classes represent the same data as their parent
class. Everything else follows naturally.

Best,
Alex Ogier
On Aug 18, 2013 12:32 AM, "Jorge C. Leitão" <jorgecarlei...@gmail.com>
wrote:

> Hi there.
>
> I was working with proxies models and I found an odd behavior on a
> QuerySet, and I ask here whether it should be documented.
>
> Consider the following code:
>
> from django.db import models
>
> #from model_utils.managers import InheritanceManager
>
> class Generic(models.Model):
> pass # comment this pass on second test
> #objects = InheritanceManager()
>
> class Specific(Generic):
> class Meta:
> proxy = True
>
> class SpecificA(Generic):
> pass
>
> Specific.objects.create()
> SpecificA.objects.create()
>
> print Generic.objects.all()
> print Specific.objects.all()
> print SpecificA.objects.all()
> #print Generic.objects.all().select_subclasses()
>
> Specific.objects.all().delete()
> SpecificA.objects.all().delete()
>
> The output is:
>
> [, ]
> [, ]
> []
>
> Why there are two  in the second list? I would
> expect 1 instance (the database has 2 rows in Generic and one 1 row in
> SpecificA).
>
> Furthermore, I also realized that the InheritanceManager (from
> django-model-utils<https://django-model-utils.readthedocs.org/en/latest/managers.html#inheritancemanager>
> ) is doing something odd on proxy models, which could be due to the
> previous behavior. Uncommenting the three commented lines of the previous
> code and commenting pass, the fourth print gives
>
> [, ]
>
> I would expect  instead of  object>.
>
> I tested this behavior in Django 1.5.2 and 1.6 and the results are
> equivalent.
>
> Can someone double check this and confirm that this behavior is odd?
>
> I searched in the documentation but I didn't found any reference that a
> Query on the proxy model returns instances subclasses of the parent model,
> instantiated as the proxy model itself. If this is the expected behavior,
> shouldn't we document it? Nevertheless, it seems to me difficult to assume
> that print Specific.objects.all()returns an instance created by
> SpecificA.objects.create().
>
> If this is not expected behavior, should I open a ticket with it?
>
>
> Cheers,
> Jorge
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Security Advisory: BREACH and Django

[Alex Ogier]

That's too hard to enforce. It would mean that you can't show user content
on any public page, or any page that you want to be accessible from outside
links. For example, you couldn't show blog comments to unregistered users.
It would be too disruptive. Modifying the format of the secret token is a
much better idea -- you only need to obfuscate it enough to defeat the
compression scheme, not an adversarial attacker.


On Wed, Aug 7, 2013 at 3:23 AM, Simon Blanchard  wrote:

> I think they nibble at it. They look at the compressed length - the
> shorter the compressed length closer they are. But if an incorrect CSRF was
> never reflected there would be nothing for them to nibble at. It says this
> in the paper:  "However, we remark that requiring a valid CSRF token for
> all requests that reflect user input would defeat the attack."
>
>
>
> On Wed, Aug 7, 2013 at 3:13 PM, Curtis Maloney  > wrote:
>
>> They don't try to guess the CSRF directly, AIUI.
>>
>> They use a form field to affect their test.
>>
>> The easiest solution I can see is the one mentioned in the document --
>> instead of outputting the raw value, output SALT || (SALT ^ TOKEN) so the
>> actual value is never in the response, but it can be retrieved by simply
>> xoring it with the salt.  The salt is changed every request.
>>
>> --
>> Curtis Maloney
>>
>>
>>
>> On 7 August 2013 16:56, simonb  wrote:
>>
>>> How about requiring that if csrfmiddlewaretoken is set, no matter what
>>> http method (GET, POST...), it is correct otherwise 403 response.
>>>
>>> Simon
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Supported Python versions for Django 1.7

[Alex Ogier]

Debian Wheezy and Ubuntu 12.04 LTS are both on Python 3.2.


On Mon, Jul 1, 2013 at 5:44 PM, VernonCole  wrote:

>
> Dropping support of 3.2 would potentially aid projects which have not yet
> converted to Python 3, since Python 3.3 supports u"Unicode Literals" but
> 3.2 does not. Skipping over the early 3.x versions vastly eases transition
> from 2.6 to 3.3.
>
> Besides, what are the chances that someone running Python 3.n is _not_
> running 3.3?
> --
> Vernon Cole
>
>
> On Friday, June 28, 2013 8:17:22 AM UTC-6, Aymeric Augustin wrote:
>>
>> Hello,
>>
>> We just forked the stable/1.6.x branch. The development of Django 1.7
>> starts now!
>>
>> As far as I can tell, there's a consensus on dropping support for Python
>> 2.6. That will allow us to remove the vendored copy of unittest2 and to
>> take advantage of datastructures introduced in Python 2.7 like OrderedDict.
>>
>> I think we can continue supporting Python 3.2 in addition to Python 3.3
>> and 3.4. But if you see good reasons to drop it, I'd like to hear them!
>>
>> Thank you,
>>
>> --
>> Aymeric.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: first() and last(), earliest() and latest()

[Alex Ogier]

QuerySets don't support indexing. I'm not entirely sure why, but I
think the reason is to encourage more efficient database usage, since
naive usage of indexing would lead to many repeated LIMIT 1 OFFSET N
type queries. Forcing people to slice first encourages them to think
about exactly how many results they need and evaluate them all at
once.

On Thu, May 16, 2013 at 11:06 AM, Lee Trout <leetr...@gmail.com> wrote:
> Let me clarify that I would expect both qs[:1][0] and qs[0] to raise
> IndexError if there were no results.
>
>
>
> On Thu, May 16, 2013 at 11:05 AM, Lee Trout <leetr...@gmail.com> wrote:
>>
>> That's what I thought- But why not just qs[0]?
>>
>> Doesn't qs[:1] and qs[0] both cause a LIMIT 1 on the query? It seems that
>> the [:1] is unnecessary. I would expect both to raise IndexError.
>>
>>
>>
>> On Wed, May 15, 2013 at 11:39 PM, Alex Ogier <alex.og...@gmail.com> wrote:
>>>
>>> Significantly better. The latter method loads every single model in the
>>> queryset into Python, potentially the whole database!
>>>
>>> On May 15, 2013 9:24 PM, "Lee Trout" <leetr...@gmail.com> wrote:
>>>>
>>>> Is qs[:1][0] better form than list(qs)[0]?
>>>>
>>>>
>>>> On Wed, May 15, 2013 at 7:48 AM, Selwin Ong <selwin@gmail.com>
>>>> wrote:
>>>>>
>>>>> I've updated the first() and last() to not accept any arguments. Please
>>>>> review it and let me know if there's anything else I need to change.
>>>>> Hopefully this can get merged in during the sprints and make it into 1.6 
>>>>> :).
>>>>>
>>>>> The pull request is here: https://github.com/django/django/pull/1056
>>>>>
>>>>> Best,
>>>>> Selwin
>>>>>
>>>>> On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
>>>>>>
>>>>>> > > I initially modeled "first()" and "last()"'s behaviors to mimic
>>>>>> > > "latest()", but in this new pull request, you can pass multiple
>>>>>> > > field names
>>>>>> > > into "first()" and "last()" so it behaves like "order_by()". It's
>>>>>> > > more
>>>>>> > > flexible and requires less typing, but I wonder if we should just
>>>>>> > > get rid
>>>>>> > > of the optional field arguments and rely on "order_by" for
>>>>>> > > ordering. "There
>>>>>> > > should be one-- and preferably only one --obvious way to do it".
>>>>>> >
>>>>>> > Considering "There should be one-- and preferably only one --obvious
>>>>>> > way to
>>>>>> > do it", I definitely prefer to rely on order_by to do the ordering,
>>>>>> > not on
>>>>>> > first.
>>>>>> >
>>>>>> > .order_by('name').first()
>>>>>> >
>>>>>> > is clear and readable in my opinion.
>>>>>>
>>>>>> My thoughts exactly, we already have one method that does ordering, I
>>>>>> don't think it is necessary to make these methods incorporate that
>>>>>> functionality. If we did, we might argue that other QuerySet
>>>>>> operations could be supported as well and that would just result in a
>>>>>> bloated API. Especially if there's no performance gain (the QuerySet
>>>>>> would be cloned anyway), and it only saves a few lines of code.
>>>>>>
>>>>>> Also, skimming through this thread, I think there was a consensus on
>>>>>> first() and last() not taking any ordering arguments, i.e. the first
>>>>>> proposed syntax:
>>>>>>
>>>>>> .filter(last_name__startswith='b').order_by('last_name').first()
>>>>>>
>>>>>> Michal
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Django developers" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to django-developers+unsubscr...@googlegroups.com.
>>>>> To post to this group, send email to
>>>>> django-developers@googl

Re: first() and last(), earliest() and latest()

[Alex Ogier]

Significantly better. The latter method loads every single model in the
queryset into Python, potentially the whole database!
On May 15, 2013 9:24 PM, "Lee Trout"  wrote:

> Is qs[:1][0] better form than list(qs)[0]?
>
>
> On Wed, May 15, 2013 at 7:48 AM, Selwin Ong  wrote:
>
>> I've updated the first() and last() to not accept any arguments. Please
>> review it and let me know if there's anything else I need to change.
>> Hopefully this can get merged in during the sprints and make it into 1.6 :).
>>
>> The pull request is here: https://github.com/django/django/pull/1056
>>
>> Best,
>> Selwin
>>
>> On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
>>>
>>> > > I initially modeled "first()" and "last()"'s behaviors to mimic
>>> > > "latest()", but in this new pull request, you can pass multiple
>>> field names
>>> > > into "first()" and "last()" so it behaves like "order_by()". It's
>>> more
>>> > > flexible and requires less typing, but I wonder if we should just
>>> get rid
>>> > > of the optional field arguments and rely on "order_by" for ordering.
>>> "There
>>> > > should be one-- and preferably only one --obvious way to do it".
>>> >
>>> > Considering "There should be one-- and preferably only one --obvious
>>> way to
>>> > do it", I definitely prefer to rely on order_by to do the ordering,
>>> not on
>>> > first.
>>> >
>>> > .order_by('name').first()
>>> >
>>> > is clear and readable in my opinion.
>>>
>>> My thoughts exactly, we already have one method that does ordering, I
>>> don't think it is necessary to make these methods incorporate that
>>> functionality. If we did, we might argue that other QuerySet
>>> operations could be supported as well and that would just result in a
>>> bloated API. Especially if there's no performance gain (the QuerySet
>>> would be cloned anyway), and it only saves a few lines of code.
>>>
>>> Also, skimming through this thread, I think there was a consensus on
>>> first() and last() not taking any ordering arguments, i.e. the first
>>> proposed syntax:
>>>
>>> .filter(last_name__startswith=**'b').order_by('last_name').**first()
>>>
>>>
>>> Michal
>>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: reconsider re-opening ticket 901

[Alex Ogier]

On Tue, May 14, 2013 at 7:38 AM, Shai Berger <s...@platonix.com> wrote:

> On Tuesday 14 May 2013, Alex Ogier wrote:
> >
> >  It's a totally new behavior that has
> > plenty of corner cases such as foreign keys, and especially
> OneToOneFields.
> >
> Another one is initializers: get() or any other method of fetching an
> object
> from the database will call __init__() with the fields as *args; this
> allows a
> model to manipulate these fields or calculate derived fields or whatever.
> refresh() may put such objects in an inconsistent state by default -- to
> prevent this, we would need a rule along the lines of "every model that
> overrides __init__() also needs to override refresh()".


There's also a systemic problem with any field that contains a python
reference. What happens when the value mutates in the database? Do you
create new instances of the value? What if it *didn't* mutate, how do you
know that?

Imagine a hypothetical python dict field, that serializes a Python dict to
JSON or a string or something and stores it in the database. What happens
in the following case?

a = A(dict_field={"hello": "world"})
d = a.dict_field
a.save()
a.refresh()
d["hello"] = "planet"# does this mutate a.dict_field? does the answer
change if somebody changed the database in between saving and refreshing?

In the case of the OneToOneField, we need that the related Python instance
not be changed if the value didn't change, or else we will break the
one-to-one correspondence of the Python instances (two related one-to-one
models point back to our model). There doesn't really seem to be any way to
do that generally, so you probably have to create new instances every time
even when the value doesn't change except in this special case. Are
OneToOneFields special enough to warrant that? What about just your average
many-to-one relationship ("b = a.b_set[0]; a.refresh(); assert b not in
a.b_set")?

Basically, having a .refresh() necessitates having mutation semantics on
fields, where previously fields (not including deferred fields) were always
immutable. Either you are loading a new instance from the database, or you
are mutating a python value and re-serializing it to the database format.
You never have to reconcile python mutations with database mutations. Even
deferred fields have only one allowed mutation - from uninitialized to
initialized.

Best,
Alex Ogier

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

Re: reconsider re-opening ticket 901

[Alex Ogier]

On Tue, May 14, 2013 at 12:09 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> As far as I can make out, that's exactly the same use case -- you're just
> making the example a little bit more explicit regarding the fact that 'a'
> is an object referred to by reference, so if 'a' is updated, b['a'] will
> also be updated.
>
> The point I was trying to make is that we're *not* talking about every
> instance of "object with PK 42" being transparently updated. It's an
> explicit API call on a specific object instance.
>

I think what he is saying is that this is not just shorthand for some other
way of achieving the same behavior. It's a totally new behavior that has
plenty of corner cases such as foreign keys, and especially OneToOneFields.

This is the shortest workaround I can come up with for the .refresh()
method: "a.__dict__ = dict(a.__dict__).update(type(a).objects.get(**{a._
meta.pk.name: a.pk}).__dict__)". Unfortunately, that clobbers any non-field
attributes you've changed since you created the instance (though it
preserves new ones). Alternatively, you could iterate over Meta.fields
calling "setattr(old_a, field_name, getattr(new_a, field_name))" for each
one, but that has the problem that field setters may expect to do some
massaging of the data on the way in which can cause data corruption.
Basically this is a Hard Problem(tm) with no obvious workaround.

Best,
Alex Ogier

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

Re: reconsider re-opening ticket 901

[Alex Ogier]

On Sun, May 12, 2013 at 3:05 PM, Chris Wilson <ch...@aptivate.org> wrote:

> Hi all,
>
>
> On Sun, 12 May 2013, Shai Berger wrote:
>
>  those should probably be updated (on remote objects!) too, or else some
>>>> serious inconsistencies may be created (when the _id field changes, that
>>>> is).
>>>>
>>>
>> aa= A.objects.get(...)
>> bb= aa.b
>> (some other operation, changing aa.b_id in the database)
>> aa.refresh()
>>
>> Now -- unless we do something about it -- bb.a is still aa, but aa.b is
>> not bb
>> and not even equal to it; thus, "bb.a.b == bb" is false, which currently
>> cannot happen without serious meddling if I'm not mistaken.
>>
>
> Hibernate (as an implementation of the Java Persistence API, JPA) tries to
> do things like this by implementing a global cache of objects loaded from
> the database, so that there's only one copy of A and B in memory, which all
> references point to.
>
> This makes it possible for A, when its link to B changes to point to a
> different object B', to find all the instances of B in memory (because
> there's only one, and it's in the object cache) and update them to no
> longer point back to A.
>
> However it does this at enormous cost in flexibility, sanity and error
> recovery. I strongly recommend against going down this route:
> http://blog.old.aptivate.org/**2010/11/26/hibernate-ejb-and-**
> the-unique-constraint/<http://blog.old.aptivate.org/2010/11/26/hibernate-ejb-and-the-unique-constraint/>
>
> It's always possible to have an out-of-date model object in memory with
> Django, with or without refresh() (which just allows us to update it
> manually). I suggest we let that sleeping dog lie.


It does make sense to do this though, in the particular case of one-to-one
relationships (for the same reasons it makes sense to cache back-references
in one-to-one relationships). The reason is that this maintains a
python-only invariant that is independent of whether the relationship is
persistent in the database. There's no attempt to update all model
instances of the referred-to model, only the single one that is currently
referred to by the Python instance. This is consistent with the behavior of
setting a OneToOneField to None. For example consider the following:

bb = B()
bb.save()
aa = A(b=bb)
aa.save()
assert aa.b is bb
assert bb.a is aa   # back-reference is cached

aa.b = None   # back-reference is cleared
assert aa.b is None
assert bb.a is None

This should be consistent with the behavior when .refresh() is called -- if
that involves clearing aa.b, then bb.a should also be cleared, it's that
simple. Ideally this is done by just setting all fields via setattr(),
which will trigger this code (and any arbitrary code for user-defined
fields Django doesn't know about). In short the following should be
equivalent to the previous example:

bb = B()
bb.save()
aa = A(b=bb)
aa.save()
assert aa.b is bb
assert bb.a is aa   # back-reference is cached

aaa = A.objects.get(id=aa.id)
aaa.b = None
aaa.save()

aa.refresh()   # back-reference is cleared
assert aa.b is None
assert bb.a is None

Hopefully that clears things up.

Best,
Alex Ogier

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

Re: reconsider re-opening ticket 901

[Alex Ogier]

On Sat, May 11, 2013 at 7:55 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> I'm sure I understand this argument. Python objects are passed around by
> reference, not by value, so if you've passed in a Django object deep into
> another library, that library will be pointing at the same instance. If the
> instance is changed, everywhere holding a handle to that reference will be
> updated.
>

Yes, but that is not what foo = MyObj.objects.get(id=foo.id) does. That
assigns a new reference to a new object to the name foo. Other references,
even references to the same instance as foo, are not refreshed. This is
precisely why a .reload() method is useful -- what is wanted is to mutate
the instance that is referred to, not to create a new reference and assign
it to the old name.

To that end - I want to make sure that we're clear about what we're talking
> about here.
>
> What is on the table is essentially adding a refresh() call on an object
> instance that is an API analog of ".get(id=self.id)" (although the
> implementation will need to do a bit more than that).
>

It's not really the same at all, .reload() or .refresh() would the existing
instance in place. It's more akin to foo.__dict__ = MyObj.objects.get(id=
foo.id).__dict__

Best,
Alex Ogier

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

Re: Nested blocks in base template.

[Alex Ogier]

It looks like the only place I can find where {{ block.super }} is
documented[1] doesn't include explicitly explain how the super block is
executed, but it is certainly the reasonable thing to do: execute the super
block in the current template's context as if it hadn't been overridden.
Otherwise overriding both {{ block one }} and {{ block base }} would be
impossible.

[1]:
https://docs.djangoproject.com/en/1.5/topics/templates/#template-inheritance


On Sat, Apr 27, 2013 at 5:05 AM, Jonathan Slenders <
jonathan.slend...@gmail.com> wrote:

> Hi all,
>
> Somebody reported a bug for django-template-preprocessor. I'm wondering
> whether this is documented behaviour for the Django template language, or
> whether this is just something that happens to be this way because of the
> implementation.
>
> https://github.com/citylive/django-template-preprocessor/issues/24
>
>
> in base:
>
> some html here{% block base %}{% block one %}block 
> one{% endblock %}{% endblock %}
>
>
> In inherited:
>
> {% extends "template_base.html" %}a little bit more html here{% block 
> base %}{{ block.super }}and more html{% 
> endblock %}{% block one %}overriden block{% endblock %}
>
>
> The result of Django:
>
> some html hereoverriden blockand more html
>
>
>
> Is this documented? If so, then I need to fix it.
> (btw, django-template-preprocessor deserves an update as well. It's still
> working nice, but hasn't seen that much progress last year.)
>
>
> Thanks,
> Jonathan
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Changing deferred model attribute behavior

[Alex Ogier]

On Thu, Apr 25, 2013 at 2:10 PM, Florian Apolloner <f.apollo...@gmail.com>wrote:

> On Thursday, April 25, 2013 7:06:06 PM UTC+2, Adrian Holovaty wrote:
>>
>> Also, I should mention that this should be *optional* behavior, as the
>> current behavior is reasonable for the common case. The API for specifying
>> this "load everything" behavior is a separate discussion. Perhaps a keyword
>> argument like: User.objects.only('username', loadall=True).
>>
>
> I could imagine a Meta attribute which introduces so called "deferred
> groups" like SA has
> http://docs.sqlalchemy.org/en/latest/orm/mapper_config.html#deferred-column-loading,
> accessing one column of a group will load all columns of the group. Not
> sure if we want that level of control, but I thought it would be worth to
> look what SA can do in this regard.
>

I think groups are a very good abstraction for this problem. The two common
cases are probably "Load this column alone, because it's potentially a big
honking blob of text or binary" and "Load everything we don't have on this
object, because we are actually using it actively". Groups let you solve
both problems flexibly. The downside is that they might not be very DRY,
having to repeat group="everything" over and over if you just want to load
it all on first access.

Best,
Alex Ogier

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

Re: [GSoC 2013] Improving code quality

[Alex Ogier]

I wouldn't claim to speak for Django GSoC mentors and what they will
accept, but I can say that the "Improve Django's code/error handling"
projects have been perennial on Django's Recommended Project list for a
while now, I think without any successful proposals (though "Improve
Django's security" is philosophically somewhat similar and that *did* get
accepted and worked on last year).

I think the problem is that it's super hard to write a proposal in this
area that gets Django people nodding and saying "Yeah, this sounds really
helpful, it's definitely something we should look at." Of course a lot of
people are interesting in Django's code getting better over time, but
people are resistant to lots of little refactorings with no external
benefit, because it's usually not clear up front that the internal benefit
will be enormous and any code changes introduce the possibility of new bugs
or flaws.

Best,
Alex Ogier


On Wed, Apr 17, 2013 at 4:42 PM, Damian Skrodzki <damien...@gmail.com>wrote:

> And how would you rate the chances that these projects will be selected
> for GSoC? Or which of all proposed projects have the most priority to you?
> I'd be very happy to join Django community and have chance to improving
> code quality (not only adding new features) would also be great.
>
>
> On Tuesday, April 16, 2013 1:04:12 AM UTC+2, Russell Keith-Magee wrote:
>
>>
>> Yes - I was referring to error reporting. Although the same would be true
>> for 'best practices'.
>>
>> Yours,
>> Russ Magee %-)
>>
>> On Mon, Apr 15, 2013 at 3:22 PM, Damian Skrodzki <dami...@gmail.com>wrote:
>>
>>> Thanks for the answer.
>>>
>>> Just to be sure. As "Take the first project" you mean "2. Improved
>>> error reporting", correct? I wrote the whole post in reversed order which
>>> could confuse you.
>>>
>>> On Monday, April 15, 2013 2:18:56 AM UTC+2, Russell Keith-Magee wrote:
>>>
>>>>
>>>>
>>>> On Mon, Apr 15, 2013 at 7:51 AM, Damian Skrodzki <dami...@gmail.com>wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> After looking through proposed ideas for the current GSoC i found 2
>>>>> issues related close to the code quality which I'm interested in. These 
>>>>> are:
>>>>>
>>>>>
>>>>>1. Best practices Updates
>>>>>2. Improved error reporting
>>>>>
>>>>> Both tasks are a different but they are very closely related just to
>>>>> code quality which if very important especially in projects in size of
>>>>> Django ;). I will try to suggest that maybe merging them into one little
>>>>> bigger task would be better idea. I'll explainin characteristics of these.
>>>>>
>>>>> Take the second one as a first. This project will require trying to
>>>>> reproduce some bugs and fix some error handling in order to allow other
>>>>> developers to fix their bugs more easily. I think that trying to analyse
>>>>> code, predict all scenarios and write all expected messages seems like
>>>>> impossible task. It's better to fix tasks already reported by users. So
>>>>> here comes the list https://code.**djangoprojec**t.com/wiki/**
>>>>> BetterErrorMessages<https://code.djangoproject.com/wiki/BetterErrorMessages>
>>>>> **. **Unfortunately (or rather fortunately) I found many of the
>>>>> issues from "error handling" are outdated. On the other side it would be
>>>>> good to review that list and possibly fix that wrong messages but ... do
>>>>> you think that fixing few error handlers is enough for 2-month project?
>>>>>
>>>>> The first one will require to know best practices and then
>>>>> rewrite/update some code to follow them. I think that this could
>>>>> be continuous task, and the finish of this task if very blurred. Common
>>>>> sense tells me that we should start with refactoring from "the worst" code
>>>>> then current worst and keep doing until all project will be up to current
>>>>> best practices. When the big project is being developed constantly there
>>>>> always be some code that need refactoring.
>>>>>
>>>>> My idea would be to fix issues from bad "error messages list" which is
>>>>> definitely achievable and then start to refactoring few functionalities of
>>>>> Django that very needs it.

Re: Request method in urls.py

[Alex Ogier]

On Mon, Apr 15, 2013 at 1:22 PM, Donald Stufft <don...@stufft.io> wrote:

>
> On Apr 15, 2013, at 1:16 PM, Alex Ogier <alex.og...@gmail.com> wrote:
>
> The problem I have with fallthrough-based dispatch is that it encourages
> really expensive performance-killing patterns, where you end up doing a
> linear scan over view functions round-tripping to the database for each one
> to see if the view can handle the request. multiurl is sort of nice because
> it least it's obvious that what it's doing might be expensive, and the
> whole linear scan is collected in one place so if it gets too long it looks
> "wrong" in a Joel Spolsky sense.
>
>
> I don't see how including the method in the resolution scheme equates to
> hitting the database.
>

Oh sorry, I wasn't totally clear. I am advocating a system where people are
encouraged to make intelligent dispatch decisions like this one early in
the routing framework *instead* of with a try-catch-fallthrough pattern.
Anything that lets you avoid doing extra work through a little up-front
intelligence is a plus in my book, and I think it's a shame that there
aren't really any good hooks to make these kinds of intelligent decisions
in the routing framework. django-multiurl has already done a lot of the
heavy lifting to make multiple URLs for the same regex work in a clean way
outside of core, but it uses this onerous pattern of calling views and
expecting them to fail in a specific way. So I am proposing that it could
easily be made to have all the right hooks to make arbitrary intelligent
routing decisions.

I think we're on the same side here, except that you want this in core.

Best,
Alex Ogier

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

Re: Request method in urls.py

[Alex Ogier]

The problem I have with fallthrough-based dispatch is that it encourages
really expensive performance-killing patterns, where you end up doing a
linear scan over view functions round-tripping to the database for each one
to see if the view can handle the request. multiurl is sort of nice because
it least it's obvious that what it's doing might be expensive, and the
whole linear scan is collected in one place so if it gets too long it looks
"wrong" in a Joel Spolsky sense.

I think what's really needed is a mechanism for more intelligent dispatch
decisions. The machinery is there in principle, and django-multiurl takes
advantage of it, but there's a bottleneck which is that in order for a view
to be correctly registered as a URL resolver with reversal, you have to go
through the narrow waist of the url() factory function. This means that
while multiurl is able to pretend to be like include() and delegate to its
child URL resolvers (which I think is what makes reverse() work), it can't
really add intelligence to its view dispatch, it can only sit on the
outside watching responses/catching specific errors, and you end up with N
copies of the regex (though perhaps this is actually a good thing, since it
means you can pass different arguments to different views).

So for example, if you wanted to implement your own intelligent dispatch
function, you are forced to go digging into the internals to find things
like the fact that kwargs passed to the url() function end up as the
default_kwargs attribute on RegexURLResolver instances. Maybe the best
option is to ask Jacob to extend multiurl to support arbitrary dispatch
mechanisms that work in *front* of the URL resolver instead of behind it,
maybe via a callback in multiurl. The following looks like it would be just
as easily added to multiurl as to core, and not that much more onerous:

from multiurl import multiurl, method_dispatch

urlpatterns = patterns('',
multiurl(
url('^objects/$', 'views.create_object', methods=['post',
'put'], name='create_object'),
url('^objects/$', 'views.get_objects', name='list_objects'),
dispatch = method_dispatch
)
)

You might even convince Jacob to make multiurl do a lot of intelligent
things with those kwargs for free (no callback required). For example just
have it filter the views it tries to only the set that matches the HTTP
method if given. There's probably other types of dispatch that are
naturally expressed as properties of the URL object once you allow multiple
URL objects per regex, such as dispatching by the Accept or Accept-Language
headers. All of this stuff falls under multiurl's purview, at least if and
until core supports fallthrough URLs.

Best,
Alex Ogier


On Mon, Apr 15, 2013 at 7:54 AM, Tom Christie <christie@gmail.com>wrote:

> This proposal is actually *very* similar to the 'URL
> dispatcher fall-though' 
> thread<https://groups.google.com/d/msg/django-developers/64I3Qy4OH-A/RqKv_GCfLREJ>that
>  came up recently.
>
> I don't think it'd take much adjustment to take Jacob's django-multiurl
> project <https://github.com/jacobian/django-multiurl> and adapt it to
> deal with method-based dispatching rather than fall-through based
> dispatching.
>
> You should be able to end up with an API that looks something like this:
>
> from methodurl import methodurl
>
> urlpatterns = patterns('',
> methodurl(
> url('/objects/$', app.views.create_object, methods=['post',
> 'put'], name='create_object'),
> url('/objects/$', app.views.list_objects, methods=['get'],
> name='list_objects'),
> )
> )
>
> Personally, I'm not particular convinced on the merits of method based
> routing, but that's not really the issue.
> The important point is that this is something that you should be able to
> do without needing to modify anything in core Django.
>
> Regards,
>
>   Tom
>
> On Saturday, 13 April 2013 22:48:44 UTC+1, Brantley Harris wrote:
>>
>> There's a line in the django URL Dispatcher documentation that is pretty
>> weird:
>>
>> The URLconf doesn’t look at the request method. In other words, all
>>> request methods – POST, GET, HEAD, etc. – will be routed to the same
>>> function for the same URL.
>>
>>
>> Well, why?  Most modern web frameworks allow you to specify the method in
>> the routing configuration, Django seems to be an exception in this respect.
>>
>> It would be extremely easy to implement, and would lead to vastly better
>> code across new projects, including a simpler way of writing rest style
>> interfaces:
>>
>> url('^objects/$', 'views.create_object', methods=['post', 'put'],
>> name='create_object'),
>> url('^objects/$', 'views.get_objects', name='l

Re: Request method in urls.py

[Alex Ogier]

I agree, I think there are use cases for both types of dispatch, and it
seems clean and well-defined to make a route that is valid for only a
subset of HTTP methods. I guess there are a few corner cases to think
about, for example should Django's url resolver start returning 405s
instead of 404s when it's just the method that doesn't match? But that kind
of stuff is easily worked out. I like the syntax too, a list passed as a
kwarg to the url() function. So +1 from me.


On Sun, Apr 14, 2013 at 4:29 PM, Brantley Harris wrote:

> On Sun, Apr 14, 2013 at 2:40 PM, Luke Plant  wrote:
>
>> One reason for not doing this kind of despatch is that handling for
>>  different HTTP methods often involves a lot of common code. The classic
>> form workflow would become longer, more complicated and/or less DRY if
>> it was implemented using two functions instead of one:
>>
>> https://docs.djangoproject.com/en/dev/topics/forms/#using-a-form-in-a-view
>>
>> So, I would disagree that dispatching on HTTP verb would lead to vastly
>> better code - it could easily make things worse.
>>
>>
> Form handling seems like the only common place that a view would want to
> handle different methods coming in, most of the time it makes much more
> sense to break up the view into one for each HTTP Method.  In essence, what
> we're doing is creating our own mini-dispatch in the view and it's clumsy
> most of the time and leads to less RESTful layouts.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: django.utils.simplejson + stdlib json

[Alex Ogier]

This problem was gonna have to be eventually sorted through no matter what:
the endgame was decided to be "json from the standard library everywhere"
which means any projects doing simplejson.dumps([django internals]) would
inevitably be affected sooner or later. In theory it's just as distasteful
and wrong to perform simplejson.dumps(, cls=json.JSONEncoder) as it is
to perform json.dumps(, cls=simplejson.JSONEncoder), however due to the
practical concern that for the time being the latter works and the former
doesn't, it might have been worth keeping a shim specifically when
subclassing JSONEncoder. Of course, there's no guarantee that future
releases of simplejson won't make the latter every bit as broken, and
eventually Django core is going to require that everyone who uses Django
internals use json instead of simplejson anyways, so it's of dubious
benefit, and I don't think it's worth re-adding.

Best,
Alex Ogier


On Sat, Apr 13, 2013 at 5:34 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 13 avr. 2013, at 22:13, Jeremy Dunck <jdu...@gmail.com> wrote:
>
> > After reading that ticket, I'm not sure what Alex and I are
> > disagreeing on.  I was suggesting using django.utils.simplejson
> > internally until it's removed, so that at least people could be
> > consistent with django itself.  That way, DjangoJSONEncoder would be a
> > simplejson.JSONEncoder (if simplejson is installed) until we remove
> > the shim.
>
> I see — I hadn't understood that you were proposing this.
>
> > Anyway, since we've already deprecated utils.simplejson, since we've
> > already done the damage here, and since doing a release to fix this is
> > probably not going to help that many people (they've either already
> > fixed their backwards-incompat or aren't planning on going to 1.5 any
> > time soon)... maybe I agree we should leave it alone.
>
>
> Yes, maybe we could have handled this differently, but at this point the
> cure would be worse than the disease :|
>
> --
> Aymeric.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: django.utils.simplejson + stdlib json

[Alex Ogier]

I think what he is saying is that many third-party libraries call the
equivalent of django.utils.simplejson.dumps("...",
cls=DjangoJSONEncoder) which, despite django.utils.simplejson only
being in a pending deprecation state, is broken.

On Thu, Apr 11, 2013 at 9:22 PM, Alex Gaynor  wrote:
> When doing what? What do I need to do to trigger this?
>
> Alex
>
> On Apr 11, 2013 6:16 PM, "Jeremy Dunck"  wrote:
>>
>> If a user of django has simplejson installed, django itself will use both
>> the stdlib and simplejson.
>>
>> On Apr 11, 2013, at 5:54 PM, Alex Gaynor  wrote:
>>
>> I basically agree with what Bob said on the ticket, it's unclear to me
>> from your email how this manifests, other than trying to use something from
>> the standard library with simplejson, which is obviously wrong.
>>
>> Alex
>>
>>
>> On Thu, Apr 11, 2013 at 5:51 PM, Jeremy Dunck  wrote:
>>>
>>> I've just seen a documented example of this breaking things in the wild.
>>>
>>> https://github.com/simplejson/simplejson/issues/37
>>>
>>> I think we broke backwards-compat here - django 1.5.1. plus sentry
>>> 5.4.5 dies because django's own DjangoJSONEncoder depends on stdlib
>>> json, but sentry (and lots of things) use django.utils.simplejson,
>>> which uses simplejson if available.
>>>
>>> Unfortunately, this is incompatible - we kept utils.simplejson as a
>>> compat shim, but I think until it goes away, we should keep using it
>>> internally as well.
>>>
>>> Alternatives?
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at
>>> http://groups.google.com/group/django-developers?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>>
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right
>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: 125F 5C67 DFE9 4084
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

Re: Support for WSGI applications within Django (Ticket #12091)

[Alex Ogier]

On Thu, Apr 11, 2013 at 1:02 PM, Carl Meyer <c...@oddbird.net> wrote:
> On 04/11/2013 08:31 AM, Gustavo Narea wrote:
>> I decided to reimplement the patch I created 3 years ago in a separate
>> project (twod.wsgi
>> <http://pythonhosted.org/twod.wsgi/manual/embedded-apps.html>), which
>> means that it's possible to do this without changing Django. However, it
>> doesn't support embedding Django projects because of Django's use of
>> global data (DJANGO_SETTINGS_MODULE and django.conf.settings), which I
>> think can only be solved by introducing thread locals in django.conf. At
>> the moment, the only way to accomplish this would be by proxying the
>> second Django site with inter-process communication (e.g., CGI, FastCGI
>> or HTTP).
>
> If I understand correctly, this latter limitation is not something that
> would be solved by integrating twod.wsgi into Django core. Are there any
> issues or problems with twod.wsgi that would be solved by integrating it
> into core?

There's a wiki article on the global state issue in Django at
https://code.djangoproject.com/wiki/GlobalState but this is unlikely
to be solved soon. It's something of a painful transition, because
Django has built up a large ecosystem that depends on this global
state. The reason is basically that it simplified implementation
greatly, especially considering that Python's module/namespace system
is deeply global. Frameworks like Flask have worked hard to avoid
global state from the very beginning, for example Flask requires all
"official extensions" to support multi-tenant applications explicitly,
and recommends a pattern where WSGI applications are created by a
factory function. Changing the Django ecosystem to allow for reliable
multitenancy would be prohibitively disruptive.

>> So, do you agree that Django should have built-in support for running
>> WSGI applications from inside views?
>
> I'm inclined to agree with Aymeric's position on the ticket: this is a
> useful feature for some scenarios, but it works just fine as a
> standalone project, and I just don't see enough demand for it to justify
> adding the maintenance burden for it to core.
>
> Carl

I think this is a common (and I think correct) response to many
feature requests: If there is anything in core that is blocking the
external implementation of a feature like this, it's worth looking at,
else just implement it outside of core. Particularly in this instance
since it will still be impossible to embed Django applications
anyways.

Best,
Alex Ogier

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

Re: URLField should allow scheme to be empty

[Alex Ogier]

After poking around a bit[1], it appears that URLFields are used almost
exclusively for canonical links to webpages, and are not typically used as,
say, the target of internal redirects, or resources that are loaded on a
page. In addition, it looks like the code from ticket 5331 that
automatically adds 'http://' that I referred to as a bug in Django was long
ago reverted[2]. So it seems counterproductive to do anything to disrupt
the current expectations of URLField users, which is that the field is an
absolute URL with scheme, host, the whole shebang. So I change my previous
+1 to a -1. If you want to have a field that allows relative or
scheme-relative URLs, creating your own field is the way to go.

Best,
Alex Ogier

[1]:
https://github.com/search?q=language%3Apython+URLField=commandbar=Code
[2]:
https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L1323


On Wed, Apr 3, 2013 at 7:38 PM, Atul Bhouraskar
<atul.bhouras...@gmail.com>wrote:

> As per RFC 3986 (see section 4, in particular 4.2) all of the following
> are valid:
>
> Absolute URI
> http://www.example.com/images/xyz.png
>
> Network path reference
> //www.example.com/images/xyz.png
>
> Suffix reference (frowned upon but valid?)
> www.example.com/images/xyz.png
>
> Absolute path reference
> /images/xyz.png
>
> Relative path references
> images/xyz.png
> ../images/xyz.png
>
> Should URLField allow all of them? Or do we need options to selectively
> allow/disallow URL components? Or maybe have AbsoluteURLField,
> NetworkPathURLField etc?
>
> Only an absolute URI is *always* relevant. Network path references (and
> relative path references) are only relevant in the context of a web page
> loaded in a browser (e.g. a URL to be rendered within the context of an
> email only makes sense if absolute).
>
> In any case (in my opinion) the URLField should not automatically add a
> missing http: - it should either reject the contents or allow it as per
> documented rules.
>
> Atul
>
>
> On 4 April 2013 07:26, Alex Ogier <alex.og...@gmail.com> wrote:
>
>> Don't add an option, it's not needed. URLs with blank schemas are valid,
>> it's just a bug that Django adds 'http://' in that case. So make a
>> ticket, +1 from me.
>>
>> Best,
>> Alex Ogier
>>
>>
>> On Wed, Apr 3, 2013 at 4:24 PM, Juan Pablo Martínez <jpm...@gmail.com>wrote:
>>
>>> I love it.
>>> If URLField has an option like "scheme_required=False" or something like
>>> that.
>>> No behaviour is the "correct", append or not append scheme. The option
>>> to our needs seems to be more correct.
>>>
>>> Regards,
>>>
>>>
>>> On Wed, Apr 3, 2013 at 5:14 PM, SteveB <smbroo...@gmail.com> wrote:
>>>
>>>> How to avoid those browser warnings about mixing secure and insecure
>>>> content on a web page?
>>>> Wouldn't it be great to be able to specify a URL for a resource (be it
>>>> a script, image, iframe etc.)  such that if the current page is insecure
>>>> (using a http:// scheme) the content would be fetched using the same
>>>> scheme?
>>>> And when the current page is secure (using a https:// scheme) the
>>>> resource would also be fetched as if it had a https scheme?
>>>>
>>>> Well you can, just leave out the scheme in the URL. That is, specify it
>>>> as "//example.com/some/path/" and the browser will apply the same
>>>> scheme as the parent page.
>>>>
>>>> Great! - But, it is not possible to specify a URL such as this in a
>>>> Django URLField. Thanks to https://code.djangoproject.com/ticket/5331,
>>>> a blank scheme will be cause the field verification to insert "http" as the
>>>> scheme, and you lose the flexibility described above.
>>>> It is currently not possible (in Django 1.5.1) to get a URLField
>>>> validating with a blank scheme, so the ability to specify a URL for a
>>>> resource which can be follow the scheme of the parent page is not possible.
>>>>
>>>> I content that the 5331 ticket may not have taken into account the
>>>> flexibility which the empty scheme offers on web pages, and I urge that it
>>>> be reconsidered.
>>>>
>>>> What do folks think?
>>>> SB
>>>>
>>>>
>>>>  --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django developers" group.
>>>> To unsubscribe from this group and stop receiving em

Re: URLField should allow scheme to be empty

[Alex Ogier]

Don't add an option, it's not needed. URLs with blank schemas are valid,
it's just a bug that Django adds 'http://' in that case. So make a ticket,
+1 from me.

Best,
Alex Ogier


On Wed, Apr 3, 2013 at 4:24 PM, Juan Pablo Martínez <jpm...@gmail.com>wrote:

> I love it.
> If URLField has an option like "scheme_required=False" or something like
> that.
> No behaviour is the "correct", append or not append scheme. The option to
> our needs seems to be more correct.
>
> Regards,
>
>
> On Wed, Apr 3, 2013 at 5:14 PM, SteveB <smbroo...@gmail.com> wrote:
>
>> How to avoid those browser warnings about mixing secure and insecure
>> content on a web page?
>> Wouldn't it be great to be able to specify a URL for a resource (be it a
>> script, image, iframe etc.)  such that if the current page is insecure
>> (using a http:// scheme) the content would be fetched using the same
>> scheme?
>> And when the current page is secure (using a https:// scheme) the
>> resource would also be fetched as if it had a https scheme?
>>
>> Well you can, just leave out the scheme in the URL. That is, specify it
>> as "//example.com/some/path/" and the browser will apply the same scheme
>> as the parent page.
>>
>> Great! - But, it is not possible to specify a URL such as this in a
>> Django URLField. Thanks to https://code.djangoproject.com/ticket/5331, a
>> blank scheme will be cause the field verification to insert "http" as the
>> scheme, and you lose the flexibility described above.
>> It is currently not possible (in Django 1.5.1) to get a URLField
>> validating with a blank scheme, so the ability to specify a URL for a
>> resource which can be follow the scheme of the parent page is not possible.
>>
>> I content that the 5331 ticket may not have taken into account the
>> flexibility which the empty scheme offers on web pages, and I urge that it
>> be reconsidered.
>>
>> What do folks think?
>> SB
>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> juanpex
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Changes to django's settings module

[Alex Ogier]

All of the changes you describe are what I would call "magic". Magic has a
downside: it's hard to understand and debug. As it currently stands, Django
has exactly one form of settings magic: there is a DJANGO_SETTINGS_MODULE
environment variable that adjusts where the settings are found. This is
easy to document and point to. "My settings aren't working, what is going
on?" "Check DJANGO_SETTINGS_MODULE." "Why does this setting have this wonky
value that's not the default?" "Read the source code to your
DJANGO_SETTINGS_MODULE."

Everything you describe is possible to do yourself explicitly if you just
want it for your own app. Want to override from environment variables?
os.environ.get("VARIABLE", "default value"). Reading from ini files?
ConfigParser.SafeConfigParser("my.ini"). The database is tricky because you
can't use the ORM without a chicken-and-egg problem, but it would be even
more confusing if you *have to* import from django.conf (for BaseSettings)
but you *aren't allowed to* import from django.db.

django-configurations sits entirely in front of Django, which is the right
place for it to sit. Forcing everything through the narrow bottleneck of a
single settings module is *a good thing*. It makes things explicit and
debuggable. Other python frameworks have similar bottlenecks. Pylons has a
master config file (ini format) that you specify on the commandline, and
several python files in expected locations. Flask is less obvious, it has
no magic files at all, but at some point you make a project-wide instance
of flask.Flask and pass it to WSGI or a ./manage.py you write yourself and
you set config on it manually, for example
app.config.from_object("myapp.MyConfig").

The only reason for having these SettingsCollectors in core is to allow
redistributable apps like django-configurations to do magic. That is, so
they can say, "Install django-configurations, and suddenly every setting
can be overridden from the environment!" This seems like a bad idea, versus
"Install django-configurations, and now you have a new tool in your toolbox
to put in settings.py that imports from the environment!"

Best,
Alex Ogier



On Thu, Mar 14, 2013 at 3:42 PM, Omer Katz <omer.d...@gmail.com> wrote:

> You haven't referred to the pull request.
>  The pull request <https://github.com/django/django/pull/899> itself
> currently just refactors the settings module in order to have better
> extensiblity hooks and to clarify the code.
> The pull request introduced the SettingsCollector class which allows you
> to costumize how exactly the settings are collected.
> The LazySettings class now accepts a constructor parameter that allows you
> to switch the settings class. The Settings class allows you to replace the
> SettingsCollector class through a constructor parameter as well.
> The first question is if this refactoring is needed and welcome. In my
> opinion it is even if you don't need it.
> The simplest example is when you want an environment variable to always
> override a setting. You might want it because your database server is down
> and you want to  at point to a backup server without changing the code and
> thus releasing a new temporary patch version or load all settings from an
> *,ini file, from the database and probably other scenarios I can't come up
> with right now (I'm after 3 glasses of wine :):).
>  Django could supply multiple SettingsCollectors to choose from and keep
> the current beahvior for backwards compatibility until 2.0 if needed or
> until forever if the default behavior is desired.
> It enables much more room for flexability for developers who have a
> special need for different form of settings files.
> If I were to extend the SettingsCollector to support loading packages as
> well we might get a standard way to load settings for different
> environments.
> You can easily develop a common settings package or module for that matter
> and than override it with a specific package or module for each deployment
> using another SettingsCollector class.
> I see much benefit in this refactoring and I hope that it will be accepted.
> I hope I made my intentions clearer.
>
> בתאריך יום רביעי, 13 במרץ 2013 19:27:02 UTC+3, מאת Omer Katz:
>
>> Lately I implemented some changes for django's settings module .
>> I refactored the whole module in order to have more extension points.
>> With #20040 <https://code.djangoproject.com/ticket/20040> it is now
>> possible to inject the Settings class that will be used by the LazySettings
>> object and I introduced a new class called SettingsCollector that allows
>> the developer to costumize how django will collect it's settings.
>> This enabled me to write the real code that will allow loading the
>

Re: Changes to django's settings module

[Alex Ogier]

I think the important point is that all of these techniques for
constructing settings are done without the help of Django (and in fact
*should* be done without the help of Django, because some parts of Django
expect to import a settings module that isn't under construction). I don't
know if there is a good way to document these practices -- it's not an
easily searchable topic, and more than a single settings.py is just added
confusion for little benefit until you need to care about deploying to
multiple contexts (it's not good tutorial material). Maybe somewhere in the
how-tos on deployment we could write up some good practices for managing
settings in multiple contexts -- that would be more welcome than code in
Django core, I think. Midterms end today for me, so maybe I will try
writing up some of the practices that make managing settings easier for me
later tonight.

Best,
Alex Ogier


On Thu, Mar 14, 2013 at 9:16 AM, Val Neekman <v...@neekware.com> wrote:

> Yeah, split by role is what I have done.
>
> settings/default.py (absolute necessities)
> settings/deploy.py (inherits default.py & adds production specifics)
> settings/debug.py (inherits deploy.py & overwrites debug stuff)
> settings/test.py (inherits deploy.py & overwrites test specific)
> settings/external.py (holds aws, google, and other social keys)
>
> The above is coupled with:
>
> bin/debug.py (= manage.py on development server)
> bin/deploy.py (= manage.py on production server)
> bin/test.py (= manage.py on integration server)
>
> This has been working very well for me.
>
> No loose files, everything has a directory to live in.
> Very easy to manage.
>
> Val
>
>
> On Wed, Mar 13, 2013 at 9:32 PM, Russell Keith-Magee
> <russ...@keith-magee.com> wrote:
> >
> > On Thu, Mar 14, 2013 at 1:08 AM, Alex Ogier <alex.og...@gmail.com>
> wrote:
> >>
> >> I find the value of separate settings modules is not splitting them by
> >> topic, but overriding them in specific contexts, like staging,
> production
> >> and development. Your implementation (and, I think, any solution that
> >> compiles multiple settings modules independently) don't have a way to
> >> specify orderings in a non-magical way. That's why I prefer explicitly
> >> importing some common settings into one module and overriding them
> >> piecemeal. The Zen of Python says "Explicit is better than implicit"
> and I
> >> think that is the case here. Packages provide settings and reasonable
> >> defaults. If you want to modularize them, you are free to do so
> yourself. I
> >> think composing settings internally is just added complexity for little
> >> benefit.
> >
> >
> > I agree with Alex.
> >
> > Splitting settings files in the way you've described in your patch
> doesn't
> > strike me as something that solves a problem that actually exists in
> > practice. Settings files aren't *that* long, and to the extent that
> splits
> > are needed, they're based on roles, not content -- you need "production"
> > settings, not "template" settings.
> >
> > Even if you did want to break out settings into multiple files, a master
> > file with "from template_settings import *" strikes me as a lot better
> > approach than a settings gathering process -- and that requires no extra
> > code in Django.
> >
> > Yours,
> > Russ Magee %-)
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Changes to django's settings module

[Alex Ogier]

I find the value of separate settings modules is not splitting them by
topic, but overriding them in specific contexts, like staging, production
and development. Your implementation (and, I think, any solution that
compiles multiple settings modules independently) don't have a way to
specify orderings in a non-magical way. That's why I prefer explicitly
importing some common settings into one module and overriding them
piecemeal. The Zen of Python says "Explicit is better than implicit" and I
think that is the case here. Packages provide settings and reasonable
defaults. If you want to modularize them, you are free to do so yourself. I
think composing settings internally is just added complexity for little
benefit.

Best,
Alex Ogier


On Wed, Mar 13, 2013 at 12:27 PM, Omer Katz <omer.d...@gmail.com> wrote:

> Lately I implemented some changes for django's settings module .
> I refactored the whole module in order to have more extension points.
> With #20040 <https://code.djangoproject.com/ticket/20040> it is now
> possible to inject the Settings class that will be used by the LazySettings
> object and I introduced a new class called SettingsCollector that allows
> the developer to costumize how django will collect it's settings.
> This enabled me to write the real code that will allow loading the
> settings either as a package or as a module.
> Instead of having one big monolitic settings.py you can now have a package
> that has configuration modules that are seperated by topic.
> If #20040 is accepted I can work on the new SettingsCollector that will
> either try to load a settings module or package.
> Should the new default be a package or a module? If it's a package it
> means we should also change the project_template.
> This is the working prototype <https://gist.github.com/thedrow/5153782>that I 
> wrote before I thought about creating a new SettingsCollector class.
> To test it just call monkey_patch() in your manage.py.
> We might want to allow multiple modules and packages to be loaded.
> This will help us actually use the settings_local.py in a standard way.
> What do you guys think? Am I clear enoguh? Should I explain in more detail
> what am I thinking here?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Moving database backends out of the core

[Alex Ogier]

Here's something I've been thinking about:

As a rule, assuming that backends are not bug-riddled and do not have
needlessly shoddy performance, nearly all of the value of an ORM is in the
set of frontend features it exposes to application developers. Given a
certain frontend API, then the only value in iterating the backend
independently from the frontend is to fix uncaught bugs, or to improve
performance, there's no value in adding features.

Also as a rule, adding features to a frontend independently from the
backend has little value. Without an implementation in whatever backend you
are on, it only serves as a guide for future backend development, so you
might as well push for backends to catch up in the same release cycle. (Or
the feature doesn't require backend support, but then it doesn't hurt to
reversion the backend anyways).

So basically, there's not much value in independently versioning and
maintaining frontends and backends to the ORM. This is in contrast to, say,
localflavor, where an improvement in Mongolian localization can immediately
help every Mongolian website in every Django version. So this primary
motivation for independent maintenance is not a factor in the ORM. Hence I
think the core team should include as many backends as it can handle in
core (where "handle" means test that they function properly for each
release). Oracle had been slipping, but from what I understand it's now in
the CI server and back to passing most tests.

So I see no reason to split off backends unless the maintenance burden is
such that they are chronically broken in every Django release. And every
reason to add MSSQL unless the maintenance burden is too high.

Best,
Alex Ogier


On Thu, Mar 7, 2013 at 4:03 PM, Erik Romijn <e...@erik.io> wrote:

> Hi all,
>
> It seems to me we are mixing a few different discussions here:
> 1. Should Django core have as few database backends as possible?
>  1a. If yes, which ones should stay in Django core?
> 2. What should we do, if anything, with the current situation where
>it seems difficult to guarantee the quality of the Oracle backend?
> 3. Should a MSSQL Django backend be included in Django core?
>
> Regarding question 1, I feel we should keep a fair set of backends,
> like the current one, included in Django core.
>
> Yes, we could move them to separate projects. All the same arguments
> apply here as why it's not necessarily good for a project to end up
> in contrib. However, in theory any component of Django could be moved
> out of core and be independently maintained. The whole ORM, the
> templating system, the CSRF protection, and so on. I haven't seen any
> reason why we should move the MySQL backend out, but not the templating
> system.
>
> Besides that, the close integration and development of all these parts
> is exactly the reason I like Django. When I download a version of Django,
> or upgrade, I know that all components in there will work well together.
> I can run my site on any of the supported databases, and they will all
> work together with the provided admin. I can build forms on the models
> I build with the ORM. The forms will nicely fit in with the templates.
>
> When I started using Django, I had looked at several alternatives which
> were more modular. However, they required me to make tons of choices,
> each involving numerous consequences. If I picked ORM A, I could have
> databases X, Y and Z, but no admin. For the admin I had to use ORM B,
> but that did not support database Z or many to many fields. And so on.
> When I tried Django, it was a relief to see I could download a single
> package, and everything would just work together.
>
> If we move database backends out of core, my big concern is that
> the same will happen there. This is fine for many components we use
> in many Django projects - but not for something as fundamental as the
> database backend. When the admin doesn't work on any of the officially
> supported backends, that should be a release blocker for Django itself,
> because I think it will be a blocker for the users.
>
> Regarding question 2, Oracle support, I think a great step forward has
> been made with the addition of Oracle to the Django continuous
> integration setup. That alone should help us improve the consistent
> quality of Oracle support.
>
> cheers,
> Erik
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.

Re: Moving database backends out of the core

[Alex Ogier]

It's worth mentioning that Django appears in the Python Tools for Visual
Studio (it's one of the default project templates)[1]. There's recent
introductory material on deploying Django applications to Windows Azure[2]
and Windows Server 2008[3], though it seems the older material at least
explicitly recommends MySQL and not SQL Server. I don't know if this is the
kind of thing that leads to demand among Windows folks for Windows support
for Django, and if any significant fraction of them want to use MSSQL with
Django, but Django is certainly becoming mainstream for them.

[1]: http://pytools.codeplex.com/
[2]:
http://www.windowsazure.com/en-us/develop/python/tutorials/django-with-visual-studio/
[3]:
http://www.windowsazure.com/en-us/develop/python/tutorials/web-app-with-django-and-mysql/

Best,
Alex Ogier


On Thu, Mar 7, 2013 at 12:46 PM, Jacob Kaplan-Moss <ja...@jacobian.org>wrote:

> On Wed, Mar 6, 2013 at 3:22 AM, Marc Tamlyn <marc.tam...@gmail.com> wrote:
> > I don't know why Oracle is included and MSSQL is not [...]
>
> It's essentially because a group of people made a concerted effort to
> get the Oracle backend up to snuff (around the 1.0 timeline, I think?)
> and then committed to maintaining it. Lately the original people who'd
> made that commitment have dropped off a bit, but there's always been
> enough attention to keep it up to date.
>
> If someone -- preferably a group -- stepped up and committed to
> keeping a MSSQL backend up-to-date in core, I'd be +1 on merging it
> and giving those people commit access to keep it up to date.
>
> [This is me speaking personally, not as a BDFL. It'd have to be a
> discussion, not just my fiat.]
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Proposal: deprecate and remove django.contrib.comments

[Alex Ogier]

I think it can't just disappear. Even if you can't find a maintainer, core
should put at least a little effort to make sure that an API compatible
third-party application exists that is compatible at least through version
1.8 when "import django.contrib.comments" stops working (basically, do the
work ourselves to make sure that it doesn't rely on undocumented internals
and can be cleanly split). Then, if it's not maintained, it can fester and
stop being compatible with new Django versions or whatever. If it's really
not important enough to anyone that it can stay modern outside of core,
then it will die, but we should make it a trivial matter to fork and adopt
for whoever needs it.

Anyways, +1 from me.

Best,
Alex Ogier


On Thu, Mar 7, 2013 at 12:41 PM, Luke Granger-Brown <luk...@lukegb.com>wrote:

> +1 from me too - I've only tried using django.contrib.comments once, and
> it ended up not being what I needed anyway, so I had to write my own
> comments module (Disqus was out of the question)
>
>
> On Thu, Mar 7, 2013 at 5:11 PM, Carlos Aguilar <darkange...@gmail.com>wrote:
>
>> I think i can maintain comments if you want the time you need.
>>
>> I only use few zinnia blogs, then, is not really important to me, but I
>> suppose it is important for many others developers.
>>
>> Best Regards
>>
>>
>> On Thu, Mar 7, 2013 at 11:00 AM, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>>
>>> On 7 mars 2013, at 17:48, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
>>>
>>> > This one's simple: I'd like to deprecate `django.contrib.comments`,
>>> > scheduling it to be removed in a couple of releases.
>>>
>>> +1
>>>
>>> > My rationale is this: if you don't really care much about how comments
>>> > work but just want something easy, then Disqus (and its competitors)
>>> > are easier to use and have much better features (spam prevents,
>>> > moderation, etc.). If you want something complex and specific, on the
>>> > other hand, you're better off writing something from scratch.
>>>
>>> The mere existence of django.contrib.comments implies that it's the
>>> sanctioned way to add comments to a Django application, but in 2013
>>> it's most likely not going to be the right answer. Leaving it in contrib
>>> is a disservice to many developers using Django.
>>>
>>> Even www.djangoproject.com stopped using d.c.comments in 2009.
>>>
>>> > If someone volunteers to maintain it as an external project I'll move
>>> > the code to a new repo and direct people there in the docs. If nobody
>>> > volunteers, then it'll go to the great /dev/null in the sky.
>>>
>>> Even if no one volunteers to maintain it, I'd still consider putting it
>>> on
>>> life support somewhere under github.com/django. The goal is to
>>> provide an easier upgrade path for maintainers of websites currently
>>> using it.
>>>
>>> Otherwise we'll have people stuck at the last version of Django that
>>> still contains d.c.comments.
>>>
>>> --
>>> Aymeric.
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at
>>> http://groups.google.com/group/django-developers?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>
>> --
>> Carlos Aguilar
>> Consultor Hardware y Software
>> DWD
>> http://www.dwdandsolutions.com
>> http://www.houseofsysadmin.com
>> Cel: +50378735118
>> USA: (301) 337-8541
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> You received this message because you are subscribed to the Google Gr

Re: Transforming django-admin.py to a shell script

[Alex Ogier]

On Fri, Mar 1, 2013 at 1:25 PM, Alon Nisser <alonis...@gmail.com> wrote:
> and then it could be called as `django-admin somecommend` instead of `python
> django-admin.py somecommand`.
> since python (using setuptools entry points) makes making a python script
> into a shell script quite easy I guess this has been Discussed before but I
> didn't find the discussion and the explanation why doesn't Django team deem
> this path worthy.
> I think most python web frameworks use some kind of a shell script (or using
> a customized paster/gearbox to provide this functionality) except for
> Django.

django-admin.py is already an executable script. So you don't need
`python django-admin.py somecommand`, just `django-admin.py
somecommand` should suffice. The .py suffix is a bit ugly, to be sure,
but it's not worth breaking every single introductory tutorial on the
web to fix. Besides, it does have some merit as it is consistent with
`./manage.py somecommand`, which is the recommended way to run pretty
much every command except "startproject".

Best,
Alex Ogier

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

Re: Moving from PIL to Pillow

[Alex Ogier]

On Wed, Feb 27, 2013 at 4:42 PM, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:
>
> On 27 févr. 2013, at 21:40, Marijonas Petrauskas <marp...@gmail.com> wrote:
>
> > Why isn't Pillow the recommended Django image library yet? PIL has
> > been unmaintained for almost 3 years and has a number of annoying bugs
> > (e.g. fails to open some valid JPEG files, maybe has some security
> > issues as well). Pillow, on the other hand, is a backwards-compatible
> > community-maintained fork, which has most of those issues fixed and
> > will even support Python 3 soon.
> >
> > I think this change would involve (1) running the test suite with
> > Pillow, (2) updating the documentation and (3) updating the ImageField
> > warning shown when PIL is not installed. Looks like an easy change.
> > What do you think?
>
>
> Yes, we'll have to choose a Python 3-compatible replacement for PIL.
>
> I've converted your email into a ticket: 
> https://code.djangoproject.com/ticket/19934
>
> I assume that Pillow and PIL are API-compatible. Django could fallback to PIL
> if Pillow isn't installed, to preserve backwards compatibility.
>
> --
> Aymeric


This seems like pretty much a no-brainer. PIL is a notoriously
backwards python package and more or less abandonware, and Pillow is a
well-supported fork.

As regards API-compatibility, Pillow is so much compatible that it
even installs to the same locations. Unless you manually check for it,
you shouldn't even notice that you are getting Pillow libraries
instead of PIL libraries. Which means that supporting pillow *should*
be as easy as Marijonas suggests, unless there actually are real
regressions. Just install it instead of or in addition to PIL when
testing, and update any documentation that refers to PIL and
ImageFields to recommend Pillow instead.

Best,
Alex Ogier

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

Re: TIMEZONE default

[Alex Ogier]

Hi Jonathan,

I don't know the particular history of this setting, but this sounds like
something that was done to maintain backwards compatibility. My guess is
that when Django was first released, it defaulted to 'America/Chicago' but
later on it was recognized that using UTC time on the server is a better
way of handling times. As a result, if the settings module doesn't contain
a TIME_ZONE setting, then you get 'America/Chicago' in order to be
backwards compatible, but when you make a new project you get the current
best-practice setting which is UTC.

Best,
Alex Ogier


On Sat, Feb 9, 2013 at 12:21 PM, Jonathan Loy <lo...@g.cofc.edu> wrote:

> Hey everybody,
>
> Quick question. In version 1.6 why is TIME_ZONE in
> django.conf.global_settings<https://github.com/django/django/blob/master/django/conf/global_settings.py>
>  set
> to 'America/Chicago', but in the default project template TIME_ZONE =
> 'UTC'? Shouldn't they be the same, and if so which one? Thanks for taking
> the time to read/answer my queston.
>
>
> v/r
> Jonathan
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Form.set_data method

[Alex Ogier]

The problem is that if you use your idiom, data and files are None when the
class is instantiated. This is currently a sign that the form has no data
attached. Currently, if you want to massage input data before cleaning, you
do it using either form of of overriding __init__ as you describe. But if
you call "form = MyForm(); form.set_data(request.POST, request.FILES)" then
code in __init__ runs while data and files are None, and doesn't have a
chance to run when you set them to proper values.

I'm not sure that this is actually such a concern. It is backwards
compatible, in the sense that any Django site that ran before the change
will continue to run after the change. It would be incompatible to start
using set_data instead of the constructor in Django core when it
instantiates a user-provided form class (maybe the admin does this? I can't
remember). Regardless, it adds complexity to any form subclasses, which
have to handle additional entry points for form data, and understand the
way the constructor calls the set_data method (for example, your patch
calls set_data before setting any of the other fields typically present on
a form, so subclasses may see unexpected things if they override it). So
I'm -0 due to the additional complexity for something which is already
possible and has a widely used idiom, even if it is more verbose.

Best,
Alex Ogier


On Thu, Jan 31, 2013 at 12:13 PM, Byron Ruth <bjr...@gmail.com> wrote:

> I don't want to belabor our difference in understanding/opinion, but there
> are two ways to extend __init__. Processing before super is called, and
> processing after super is called:
>
> # Common pre-processing..
> class MyForm(forms.Form):
> def __init__(self, request, *args, **kwargs):
> # Use downstream somewhere..
> self.request = request
> super(MyForm, self).__init__(*args, **kwargs)
>
> # Common post-processing..
> class MyForm(forms.Form):
> def __init__(self, *args, **kwargs):
> super(MyForm, self).__init__(*args, **kwargs)
> # tweak various field properties..
>
> In either case, the `data` and `files` attributes are set as they were
> before which means they are still available just like before. Am I missing
> something? Do you or Shai have a real example that would correct
> understanding?
>
> On Jan 31, 2013, at 11:56 AM, Alex Ogier <alex.og...@gmail.com> wrote:
>
> Byron, I think Shai is suggesting that a user's form class may do extra
> processing in __init__ on the data and files fields. If someone starts
> using the new pattern in their views, it will break those classes because
> they expect the initializer to be called with valid data when there is any.
> Your new method will bypass their customizations.
>
> Best,
> Alex Ogier
>
>
> On Thu, Jan 31, 2013 at 8:51 AM, Byron Ruth <bjr...@gmail.com> wrote:
>
>> I don't understand your argument regarding overriding `__init__`. Nothing
>> has changed in __init__, the logic for setting `data` and `files` is simply
>> moved to a method. You _can_ still pass `request.POST` and `request.FILES`
>> into the constructor. If a user extends __init__ (I do it all the time),
>> you still need (are expected) to call `super` to _finish_ initialization.
>>
>>
>> On Thursday, January 31, 2013 1:08:52 AM UTC-5, Shai Berger wrote:
>>>
>>> On Thursday 31 January 2013, Byron Ruth wrote:
>>> > Here is the ticket: 
>>> > https://code.djangoproject.**com/ticket/19668<https://code.djangoproject.com/ticket/19668>and
>>> >  the
>>> > pull request 
>>> > https://github.com/django/**django/pull/674<https://github.com/django/django/pull/674>
>>> >
>>> > One user commented on the ticket raising a concern that it could
>>> possibly
>>> > be misused if the data is set after it had been used. It is certainly
>>> a
>>> > valid concern, however it should be made clear in the docs when to use
>>> it
>>> > and/or raise an exception if `is_valid` has already been called.
>>> >
>>> > Thoughts?
>>>
>>> While this is backwards-compatible per se, using it in views is
>>> generally not
>>> backwards-compatible with user form classes (you can't tell what they do
>>> in
>>> their initializers); thus, generic views (and also some not-generic
>>> views) are
>>> forced to keep using the "old way" unless the (user) form code is
>>> altered.
>>> Which means, you'll have two ways to do the same thing (in views),
>>> without a
>>> clear preference between them.
>>>
>>> So if you want this judged as a backward

Re: Form.set_data method

[Alex Ogier]

Byron, I think Shai is suggesting that a user's form class may do extra
processing in __init__ on the data and files fields. If someone starts
using the new pattern in their views, it will break those classes because
they expect the initializer to be called with valid data when there is any.
Your new method will bypass their customizations.

Best,
Alex Ogier


On Thu, Jan 31, 2013 at 8:51 AM, Byron Ruth <bjr...@gmail.com> wrote:

> I don't understand your argument regarding overriding `__init__`. Nothing
> has changed in __init__, the logic for setting `data` and `files` is simply
> moved to a method. You _can_ still pass `request.POST` and `request.FILES`
> into the constructor. If a user extends __init__ (I do it all the time),
> you still need (are expected) to call `super` to _finish_ initialization.
>
>
> On Thursday, January 31, 2013 1:08:52 AM UTC-5, Shai Berger wrote:
>>
>> On Thursday 31 January 2013, Byron Ruth wrote:
>> > Here is the ticket: 
>> > https://code.djangoproject.**com/ticket/19668<https://code.djangoproject.com/ticket/19668>and
>> >  the
>> > pull request 
>> > https://github.com/django/**django/pull/674<https://github.com/django/django/pull/674>
>> >
>> > One user commented on the ticket raising a concern that it could
>> possibly
>> > be misused if the data is set after it had been used. It is certainly a
>> > valid concern, however it should be made clear in the docs when to use
>> it
>> > and/or raise an exception if `is_valid` has already been called.
>> >
>> > Thoughts?
>>
>> While this is backwards-compatible per se, using it in views is generally
>> not
>> backwards-compatible with user form classes (you can't tell what they do
>> in
>> their initializers); thus, generic views (and also some not-generic
>> views) are
>> forced to keep using the "old way" unless the (user) form code is
>> altered.
>> Which means, you'll have two ways to do the same thing (in views),
>> without a
>> clear preference between them.
>>
>> So if you want this judged as a backwards-compatible change, I'm -1.
>>
>> As a non-backwards-compatible change, I'd like it, but I don't think it's
>> worth the disruption, so I'm -0.
>>
>> Either way, I'm not a core dev.
>>
>> Shai.
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Shouldn't Textarea be CamelCased as TextArea?

[Alex Ogier]

It's probably just a wart from HTML. The XyzInput widgets correspond more
or less to  tags, but the Textarea widget corresponds to
. There's only two tags like this that are HTML form elements but
are not  tags, the other being , whose widget "Select"
similarly has one capital letter and no "Input" suffix. So the naming is
consistent, and agrees with the HTML tags, even though it looks a little
weird without that knowledge.

Best,
Alex Ogier


On Sat, Jan 19, 2013 at 3:26 AM, Wim Feijen <w...@go2people.nl> wrote:

> Hi guys,
>
> I was just wondering, and maybe my English language skills are
> insufficient.
>
> Django defines several widgets, like:
> TextInput
> PasswordInput
> HiddenInput
> DateInput
> DateTimeInput
> TimeInput
> Textarea
>
> Why isn't Textarea CamelCased: TextArea, like the other widgets? It seems
> inconsistent. But maybe I am missing something?
>
> -- Wim
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/1V71BI3iUBQJ.
> To post to this group, send email to django-developers@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-developers@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: First request - Modify django.core.management.color with settings option

[Alex Ogier]

Well, most GNU command line utilities have an option
--color=always|auto|never that defaults to auto. Seems like it works for
them, so replicating it for management commands makes more sense than an
environment variable to me.

Best,
Alex Ogier


On Wed, Dec 19, 2012 at 4:09 PM, Alex Gaynor <alex.gay...@gmail.com> wrote:

> I too think a setting is inappropriate for this, I'm also a little
> skeptical of an env var, is this not a bug with PyCharm?
>
> Alex
>
>
> On Wed, Dec 19, 2012 at 1:08 PM, Florian Apolloner 
> <f.apollo...@gmail.com>wrote:
>
>> I dislike a setting for this, an optional environment variable would make
>> more sense imo (since you usually don't want to set this for one project
>> but all…).
>>
>> Cheers,
>> Florian
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/django-developers/-/pV58KKtlpUMJ.
>>
>> To post to this group, send email to django-developers@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.
>>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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-developers@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: Yet another __ne not equal discussion

[Alex Ogier]

To be fair, the query you describe is significantly more expensive than
Marek's query.


On Fri, Nov 30, 2012 at 10:20 AM, Tom Evans wrote:

> On Fri, Nov 30, 2012 at 2:51 PM, Marek Brzóska 
> wrote:
> >
> >
> >
> > 2012/11/30 Tom Evans 
> >>
> >> On Fri, Nov 30, 2012 at 1:29 PM, Marek Brzóska 
> >> wrote:
> >> > Has the matter been completely put away?
> >> >
> >> > I would like to bring it up again.
> >> >
> >> > I have Articles and Categories. An Article belongs to Categories:
> >> >
> >> > class Category(model):
> >> >   pass
> >> > class Article(model):
> >> >   category = ManyToManyField(Category)
> >> >   status = CharField(max_length=10)
> >> >
> >> > Now I want all categories with articles that have status different
> than
> >> > "archived".
> >> >
> >> > I cannot do this with django's ORM!
> >> >
> >> > Category.objects.filter(~Q(article_status="archived"))
> >>
> >> What precisely is wrong with:
> >>
> >> Category.objects.exclude(article_status='archived')
> >
> > It excludes all categories that have at least one archived article.
> >
> > And I want categories that have at least one NOT archived article.
> >
> > Example: I have one category: politics. I have two articles in this
> > category: "Vote Obama!" which archived and "U.S wars" which is not
> archived.
> > Category.objects.exclude(article_status='archived')
> > will show no categories, while I want my only category to show, because
> > there is one not archived article, "U.S. wars".
>
> That's a very different question:
>
>
> Category.objects.exclude(article__status='archived').annotate(num_articles=Count('article')).filter(num_articles__gt=0)
>
> Still answerable via the ORM.
>
> Cheers
>
> Tom
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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-developers@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: Class based views: A standard hook for http-method-independent code

[Alex Ogier]

For example, you miss Http404 and other error responses, which are
implemented as exceptional control flow. In addition, you can't do any
preprocessing of the request; for example, you can't set up any invariants
before your actual view method is called.

Best,
Alex Ogier


On Wed, Nov 14, 2012 at 8:48 AM, Daniel Sokolowski <
daniel.sokolow...@klinsight.com> wrote:

>   Can you elaborate the nasty side effects you are thinking of? I can’t
> think of any that that the base views do to warrant your statement.
>
>  *From:* Aaron Merriam <aaronmerr...@gmail.com>
>  *Sent:* Friday, November 09, 2012 3:12 PM
> *To:* django-developers@googlegroups.com
> *Subject:* Re: Class based views: A standard hook for
> http-method-independent code
>
> That pattern has nasty side-effects.  It can be used in some cases but it
> fails in most.
>
> On Friday, November 9, 2012 8:28:47 AM UTC-7, Daniel Sokolowski wrote:
>>
>>   I’ve done the below in the past, the only issue with that is if you
>> have side effects in parent’s dispatch you don’t want executed but you
>> would also run that risk if you had an initialize() method work flow; in
>> the end I find dispatch() is enough in my experience.
>>
>> def dispatch(self, request, *args, **kwargs):
>> parent_dispatch_return = super(Class, self).dispatch(request, *args,
>> **kwargs)
>> ...my code based on values based on the super call...
>> return parent_dispatch_return
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Perimission field name on the new Custom User Model

[Alex Ogier]

Oh, my apologies, the proper argument to set the name of the table that is
created for a ManyToManyField is db_table instead of db_column (which just
controls the column on the user table itself). Entirely my mistake.

Best,
Alex Ogier


On Thu, Nov 8, 2012 at 8:10 PM, Christian Jensen <christ...@jensenbox.com>wrote:

> Yea, the column name was the first thing I tried - it had no effect on the
> name of the database table that was created.
>
> I am good with copying the entire ModelBackend I just thought someone
> would either want to document this fact or make it configurable.
>
> Christian
>
>
> On Thu, Nov 8, 2012 at 1:22 PM, Alex Ogier <alex.og...@gmail.com> wrote:
>
>> Django's permission system does expect there to be a user_permissions
>> property on user objects. It's possible to change django to refer to that
>> field indirectly, in the same way that it refers to
>> CustomUser.USERNAME_FIELD, but Django core developers would be unlikely to
>> accept the change because this is a rare use case. Instead, if you want to
>> clean up the database field names, I would try adding a
>> db_column="permissions" argument to the user_permissions field declaration
>> in your custom user model. That should change the database field name
>> without interfering with Django's ModelBackend.
>>
>> Best,
>> Alex Ogier
>>
>>
>> On Thu, Nov 8, 2012 at 3:27 PM, Christian Jensen <christ...@jensenbox.com
>> > wrote:
>>
>>> I was tweaking around with making an email address only User model (sans
>>> username) while still retaining the permissions stuff and ran into a small
>>> issue. I can fix it but it might need to be documented.
>>>
>>> Here is the problem:
>>>
>>> I copied over the entire AbstractUser of django.contrib.auth.models.py,
>>> made my changes I needed and just for fun changed 'user_permissions' to
>>> just 'permissions'  because I liked the name in the database to be
>>> 'account_user_permissions' instead of 'account_user_user_permissions'
>>>
>>> When I went to run it, line 44 of ModelBackend died because there is a
>>> hard reference to 'user_permissions' in the line:
>>>
>>> user_obj._perm_cache = set(["%s.%s" % (p.content_type.app_label,
>>> p.codename) for p in user_obj.*user_permissions*.select_related()])
>>>
>>> The only fix I could come up with quickly was to copy out the entire
>>> ModelBackend and fix it there. I am probably an idiot and just not know the
>>> better way to fix this.
>>>
>>>
>>> Christian
>>> --
>>>
>>> *Christian Jensen*
>>> 724 Ioco Rd
>>> Port Moody, BC V3H 2W8
>>> +1 (778) 996-4283
>>> christ...@jensenbox.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-developers@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-developers@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.
>>
>
>
>
> --
>
> *Christian Jensen*
> 724 Ioco Rd
> Port Moody, BC V3H 2W8
> +1 (778) 996-4283
> christ...@jensenbox.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-developers@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-developers@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: Custom user models in 1.5, not flexible/dry enough?

[Alex Ogier]

I agree entirely. The point of mixins is not that they are a particularly
healthy abstraction, just that they are one way of exposing the Django
permissions system, which is currently only done in full form (that is,
with is_active and is_superuser guards) in AbsractUser and User. If you
want to use Django permissions with AbstractBaseUser, you have to roll your
own, and/or depend on underscore-prefixed functions from
contrib.auth.models.

I would be +1 for a solution that exposed those permissions checking
functions so that they can be used with less boilerplate. In general I
think having an explicit contract for User models in particular contexts is
a good thing, better than hiding behind an opaque mixin. That is,

class MyUser(AbstractBaseUser):
is_active = BooleanField(...)
is_staff = BooleanField(...)
@property
def is_superuser(self):
return False
def has_perm(self, perm, obj=None):
return user_has_perm(self, perm, obj)
def has_perms(self, perm_list, obj=None):
return user_has_perms(self, perm_list, obj)
def has_module_perms(self, package_name)
return user_has_module_perms(self, package_name)

is arguably preferable to

class MyUser(AbstractBaseUser, PermissionsMixin):
pass

The advantages of the former is that it is more explicit, and perhaps more
newbie friendly, but it is currently impossible to do without duplicating
logic since user_has_perm etc. don't exist. The advantage of the latter is
that it involves considerably less boilerplate, but it freezes is_superuser
and is_staff as boolean fields on the ORM (though this could be removed
from the mixin if people prefer implementing these themselves as Florian
suggested).

The point isn't to go mixin-crazy, it's to find the best way to expose
permissions-checking (the most boilerplate-heavy of the requirements of an
admin-compatible user). The other contracts are probably better exposed as
tests in contrib.admin than as little piece-wise mixins.

Best,
Alex Ogier



On Thu, Nov 8, 2012 at 7:12 AM, Russell Keith-Magee <russ...@keith-magee.com
> wrote:

>
> Ok - so, I've been following this thread, and I should probably shed some
> light on the other side of the decision making process.
>
> I've got a history with Mixins. I was responsible for the final commit of
> Django's class-based views, which are very mixin heavy… and haven't been
> universally well received.
>
> There was a lot of very incoherent "this sucks" criticism (which -- as an
> aside -- is hideously demotivating). However, some did find a way to
> express their criticism constructively; one good example that explains the
> bigger problem is from one of Django's core team:
>
> http://lukeplant.me.uk/blog/posts/class-based-views-and-dry-ravioli/
>
> tl;dr - The root of the objection is that yes, introducing a stack of
> mixins decreases repetition - but at the cost of a greater learning curve.
> And as a result, it's harder for newcomers to get started. This isn't an
> inherently bad thing, but it *is* a tradeoff.
>
> So, I've been burned. While I still believe mixins have their place… I'm
> not rushing to go overboard again.
>
> Where does that leave swappable Users?
>
> Something like a PermissionMixin? I can certainly see a place for that.
> Django's permissions model is a very specific beast, and the current User
> model implements them in a way that could definitely be refactored for
> reuse. I can certainly see the value in splitting that out so that you
> don't have to repeat the same implementation, Truth be told, it's about 10
> lines of code to reimplement if you import the helper functions, but if
> someone were to work up a patch for this, I'd be inclined to add it.
>
> Something like AdminMixin? I'm not as convinced. The Admin User API
> interface is duck typing at it's best. Admin doesn't care *how* is_staff is
> implemented -- it just cares that the attribute is available. Splitting out
> a mixin class to make it easier to put an is_staff attribute on a model
> seems like a whole lot of unnecessary complexity
>
> Something like PersonalDataModelMixin? Definitely unconvinced on this one.
> Implementations of first_name and last_name aren't *that* hard, and
> flexibility to include or not include these attributes was one of the
> driving motivators behind swappable users in the first place.
>
> Now, ok - in the case of the latter two, you could argue that *any*
> repetition is bad repetition. However, there's repetition and there's
> repetition. Being forced to repeat hundreds of lines of complex business
> logic… sure - that's bad. Being forced to explicitly declare that your user
> model has a boolean flag to define the staff status of a user? I'm sorry,
> but that's really no

Re: Custom user models in 1.5, not flexible/dry enough?

[Alex Ogier]

So, I went ahead and implemented the most useful mixin of the three that I
defined previously, the PermissionsMixin. You can see it at
https://github.com/ogier/django/blob/permissions-mixin/django/contrib/auth/models.py#L293

This should dramatically simplify the creation of a custom User model in
the case that you are OK with Django's default permissions model (and I
think many people are). Now instead of reimplementing dumbed-down versions
of the permissions code whenever you want to use admin, you can just add
PermissionsMixin to your parent classes and *poof* your user model is
compatible with contrib.admin (though you still need to roll your own admin
class, maybe we can help here too). This would DRY up some of
https://docs.djangoproject.com/en/1.5/topics/auth/#a-full-example which
could forget about permission-handling code, and still have fully-fledged
app permissions.

I think this covers 80% of what is missing from the current class
hierarchy. Forcing every AbstractBaseUser to have a password isn't strictly
required, but seeing as Django's implementation is pretty good and we don't
want to encourage people to go rolling their own, it seems like an OK
limitation. Forms will still have to be overridden, but that was always
inevitable.


On Tue, Nov 6, 2012 at 5:02 PM, Anssi Kääriäinen <anssi.kaariai...@thl.fi>wrote:

> On 6 marras, 23:05, Alex Ogier <alex.og...@gmail.com> wrote:
> 
> > ... Since you can't actually override or change the fields of an
> abstract model anyways (so far as I know?)
>
> Allowing override of abstract parent's fields is fairly trivial
> (https://github.com/akaariai/django/compare/abstract_overrides).
>
> I don't immediately see a reason to disallow override of abstract
> parent's fields.
>
> Anyways it seems there is some room for improvement in model
> validation for abstract parent case:
>
> class Foo(models.Model):
> username = models.CharField(max_length=100)
>
> class Meta:
> abstract = True
>
> class FooOverride(models.Model):
> username = models.CharField(max_length=200)
>
> class Meta:
> abstract = True
>
> class Bar(Foo, FooOverride):
> pass
>
> print(Bar._meta.fields)
> [,
> ,
> ]
>
>  - Anssi
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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-developers@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: Custom user models in 1.5, not flexible/dry enough?

[Alex Ogier]

I consider the mixins I wrote at
https://github.com/ogier/django/blob/auth-mixins/django/contrib/auth/mixins.py<https://github.com/ogier/django/blob/auth-mixins/django/contrib/auth/mixins.py#L120>
helpful
because they decompose the old User model into some orthogonal chunks that
you can pick and choose from when writing your own user model. Russell went
a different direction, making a strictly increasing hierarchy of
functionality, AbstractBaseUser -> AbstractUser -> User.

Russell's method has some advantages. It's conceptually simpler, and python
has always handled multiple inheritance in a mildly broken way (namely, the
super(self, klass) hierarchy is wonky). Also, his contract for a User model
guarantees a single, unique field that is a primary identifier, which may
be nice for apps trying to depend on a user model. That said, I'm not a
huge fan of the lines Russell has chosen for his extensibility points.
However, he has certainly written many more Django websites than I have, so
maybe he has more insight into what is really needed.

Here's my justification for more fine-grained mixins:

- AbstractBaseUser isn't really minimal. It assumes a database-backed
password field for every user. This may or may not make sense: I have
written sites that use auth.User but do no internal authentication, instead
shelling out entirely to an external service like Kerberos, CAS, OpenID,
etc. It still is nice to have a password as a fallback, even if you don't
expose it to non-admins, so that if an external service is unavailable you
aren't locked out of the site, which may be enough justification for
leaving the password field and related authentication mechanisms on every
user.

- AbstractUser isn't very flexible. Since you can't actually override or
change the fields of an abstract model anyways (so far as I know?) the main
benefits the AbstractUser model gives you over the default User+Profile
model is that there is one less join when querying the database, and you
can avoid the ad-hoc get_profile() calls you previously needed to access
extra fields. You are still stuck with the small username field and
non-unique email addresses.

- AbstractUser is too heavy. In particular, it makes the same mistake that
auth.User does of conflating authorization with identity, when these are
actually entirely decomposable. In particular, the choice of identity as
email vs. username vs. Windows domain account vs. hidden auto-incrementing
primary key etc is totally orthogonal to the choice of authorization
mechanism as Django content-types/permissions vs. always-yes vs.
hand-rolled granular permissions etc

If you want to codify that last point, I see two major types of mixins that
would useful when implementing a user class, corresponding to the two main
choices I have to make when implementing a site. How do my users identify
themselves? and How do I control what they are authorized to do? Currently,
if I choose anything besides "My users use a username and password to log
in" for identity, I am forced to re-implement permissions from scratch,
which I probably don't want to do. And vice versa.

Moving forwards, I assume Russell is pretty invested in the current class
hierarchy. Since the Django codebase has started duck-typing the User model
anyways, I could certainly reimplement the mixin hierarchy as a reusable
app, though it would be the opposite of DRY since 90% of the code is
duplicated exactly. We could also merge the two, and implement AbstractUser
as inheriting AbstractBaseUser + UsernameMixin + PermissionsMixin. I might
try that on my branch, and see how it works out. My guess is it will work
just fine albeit with an absurdly deep inheritance tree.

Best,
Alex Ogier


On Tue, Nov 6, 2012 at 1:11 AM, Ryan Kaskel <d...@ryankaskel.com> wrote:

> I implemented a custom User model in my new project so I can sympathize
> with Ionel a bit. I wanted to change a few fields on User and have an admin
> with the same functionality as the 1.4 auth.User.
>
> This necessitated some copying and pasting to define the User's relations
> to auth.Group and auth.Permission (as well as adding is_staff,
> is_superuser, and a few help methods related to perms such as
> get_group_permissions).
>
> I also had to "re-implement" (i.e. copy, paste, and change a few fields)
> auth.User's ModelAdmin to get the admin interface looking similar (this
> included some related forms).
>
> Still though, the benefit of Russ's additions far outweigh some of these
> minor conveniences, which, to be fair, he mentioned in his draft branch
> release notes (June 4 -
> https://groups.google.com/d/msg/django-developers/YwEZUIMuIkE/g9-tAZ15RxMJ
> ):
> """
>  * The auth forms are bound to User, and don't adapt to MyUser.
>
>  * You need to roll your own admin registration for MyUser
>
>  * The admin template still asks for "usernam

Re: Proposal - ``Model.reset_state``

[Alex Ogier]

On Mon, Oct 15, 2012 at 12:16 PM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:

> Problem:
>
> a = A.objects.get(...)
> form = AModelForm(data={...}, instance=a)
> if form.is_valid():
> a = form.save()
> else:
> a.calculate_foo_field()
> a.last_attempt = datetime.now()
> a.save()  # Oops, now the instance has the bad data provided to the
> form
>
>
> Workarounds:
>
> # Get a fresh copy of ``a``
> a = A.objects.get(pk=a.pk)
> # Wasted query
> # Also, this won't work in the context of a ``select_for_update`` on
> the original instance
>
> # Use ``update`` instead
> A.objects.filter(pk=a.pk).update(last_attempt=datetime.now(), ...)
> # What about ``calculate_foo_field``?
> # Also has the ``select_for_update`` problem
>
>
> Solution:
>
> a.reset_state()  # Resets the instance's field state to the point of
> creation (using data stored in a ``_state_reset_cache`` dict)
> a.reset_foo()  # etc.
> a.latest_attempt = datetime.now()
> a.save()
>
> Problem: Uses more memory per instance
> Solution: Add ``QuerySet.cache_for_reset()`` allowing opt-in usage of the
> feature, treating ``reset_state`` as noop when instance doesn't have the
> state reset cache.


That seems like a heavy-weight solution for something that probably isn't
all that common. The same thing could be achieved by adding a method to
checkpoint the current state, or even clone the instance, which would only
incur the overhead when you know you need it. For example:

a = A.objects.get(...)
form = AModelForm(data={...}, instance=a.clone()) ## copy the state here
if form.is_valid():
a = form.save()
else:
a.calculate_foo_field()
a.last_attempt = datetime.now()
a.save()

This is easy enough to do piecemeal by adding .clone() methods to your
models, and trying to do it generically sends us even farther towards
Django models having all the bureaucracy of a C++ class with
copy-constructors, so I wouldn't advocate adding it to core. Hopefully it
addresses your use case though.

Here's an example of a similar snippet someone has written, though
obviously you want to keep the same PK instead of auto-generating a new
one: http://djangosnippets.org/snippets/904/

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: URL dispatcher slow?

[Alex Ogier]

On Wed, Oct 10, 2012 at 6:29 PM, Florian Apolloner <f.apollo...@gmail.com>wrote:

> That said, if you really think Django's urlresolver is to slow, go ahead,
> profile it and improve it, we certainly won't say no to speed improvements…
>

That's not really fair. Django core *will* say no to speed improvements if
they necessitate any backwards incompatibilities, which due to early design
decisions they often will.

The main reason Django's url resolver is slow is that it was designed to
allow some very flexible patterns. Just like middleware is slow because it
is globally configured and called on every request. And the template
language is slow because it allows arbitrary textual replacements and has a
flexible import system that defeats compilation.

Django has committed itself to backwards compatibility, which means it
tends to get larger and heavier over time, and decisions that were made
long ago have lasting impact. Speed is a real feature even in python, but
Django has very consciously chosen to prioritize other things. I consider
it a valid argument to say, "Django cares more about developer productivity
and backwards compatibility than framework speed," but "Fix it yourself" is
a hackneyed open-source truism, and "Speed doesn't matter" is more or less
self-evidently false -- especially to someone evaluating frameworks, who
may not yet have a strong opinion on what features are game-changers for
his application.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Feature request: collectstatic shouldn't recopy files that already exist in destination

[Alex Ogier]

On Mon, Oct 8, 2012 at 1:06 PM, ptone <pres...@ptone.com> wrote:

> While git may be common, and your problem not unique - this is still a
> condition of your dev environment rendering modification dates invalid.
> There might be other situations where this is the case (I've run into
> scripts that muck with modification dates based on camera/jpeg metadata).
>
> So after some further discussion on IRC - it was determined that md5,
> while somewhat common, was far from a standard, and was likely not to be
> available as remote call for network based storage backends. And so the
> final resolution is to wontfix the ticket.
>
> In the end - this lack of a universal fingerprint is just a limitation of
> our storage tools.
>
> -Preston
>

Is there a reason this fingerprint must be universal? If you're dealing
with a backend like S3, where network latency and expensive writes are a
problem, but md5 is a builtin remote call (available on any GET), why not
just do an md5 sum in the _save() method? Basically, just buffer the File
object you receive, take an md5 in python, and then make a decision whether
to upload or not. In the common case of reading from local disk and writing
to S3, this is a big win, and doesn't require cooperation from any other
backends, or standardizing on md5 as a fingerprint method.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: A bit of Django history

[Alex Ogier]

On Fri, Oct 5, 2012 at 1:41 AM, Jeremy Dunck <jdu...@gmail.com> wrote:

> It made me smile - we've come a ways since then. :)
>

This part especially made me giggle in light of the current flamewar over
Django's templating speed:

I've seen benchmarks that peg Django’s template language at four times
> faster than Kid and six times as fast as Cheetah. In fact, it’s SO fast
> that we’ve found that caching compiled templates is actually slower than
> re-rendering them on every request.


 Also, Django may have come a long way, but boy am I glad that this is
still the truth:

Django’s admin will blow your mind


 There are a lot of other good python frameworks nowadays with lots of nice
features, but this is the one that keeps me coming back to Django.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Model inheritance extended.

[Alex Ogier]

On Mon, Sep 24, 2012 at 12:33 PM, Daniel Sokolowski <
daniel.sokolow...@klinsight.com> wrote:

>   It also seems the current abstract model mechanism can do everything a
> model library can minus the model prefixing and the model grouping; that
> though I would just tackle using a naming convention, i.e.
> SimpleLibraryBook, ExtendedLibraryBook, with a BaseBook abstract class.
>

There's a big thing you cannot do without grouping models: you can't have
an abstract base class relate to another abstract base class. Django's
foreign key mechanism doesn't know how to relate to a to-be-instantiated
concrete class. This is more or less the same problem that is solved by
Russell's User model switching code: you want libraries to relate to the
User model, but you also want application writers to subclass the User
model. Russell's solution is bottom-up: you swap out the User model at
runtime, and refer to it indirectly everywhere. Jonathan's solution is top
down: you instantiate all your model classes together, resolving references
at load time. Jonathan's solution is nice because it lets you instantiate
multiple copies of the same base. Russell's is nice because it doesn't
require invasive architectural changes, such as moving all your base
classes to a single factory.

I like this solution. I don't think it strictly has to be in core though:
if I wanted to distribute a blueprint model, I can just depend on
django-model-blueprint without even requiring any changes to
INSTALLED_APPS, which means the only benefit to being in core is
canonicalizing the pattern.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: iPython behaves strangely only with Django shell

[Alex Ogier]

On Wed, Aug 29, 2012 at 10:58 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
> The following gist demonstrates a strange phenomenon, which occurs when I
> use ``python manage.py shell``, but not when I use ``ipython`` alone.
>
> https://gist.github.com/f8c2fd97647de90d915a
>
> I'm not certain whether this is a known issue, or whether it's even a Django
> bug, but certainly nothing of the sort occurs in iPython when used alone.
> This occurs with ANY name. I first noticed it when I tried to create a form,
> and there was a name error on ``forms`` on the line of my first field
> declaration.
>
> IPython 0.12.1
> Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34)
>

This is almost certainly related to https://code.djangoproject.com/ticket/18204

I can repro just as Alex Gaynor did, and the patch from the above
ticket fixes it.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Yak shaving the test framework on the way to pluggable user models (#3011)

[Alex Ogier]

On Wed, Aug 29, 2012 at 3:44 AM, Russell Keith-Magee
 wrote:
>
> I suppose you could see it as a semantic nuance. However, to my mind,
> there is a different. A skipped test is something that could -- or
> even *should* be run -- but can't due to missing some optional
> prerequisite. In this case, we're talking about tests that can't ever
> be run.  To my mind, it doesn't make sense to have those tests present
> but "skipped".

I'm not sure I see the difference between a configuration that makes a
test unnecessary and a missing optional dependency that makes a test
unnecessary. In both cases a skipped test means roughly, "A test was
found, but due to the particulars of your environment it doesn't make
sense to run it." Django users trying to validate a django deployment
can and should ignore both kinds of skipped tests. Core developers
cutting a release should investigate both kinds of skipped tests,
because it means the test coverage wasn't 100%. Since a skipped test
signals the roughly the same thing no matter the cause, there's little
reason to differentiate them.

Best,
Alex

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

Re: Python 3 str.format()

[Alex Ogier]

> Until the Python developers announce an actual timeline for removal
> (if they ever do), I can't see any reason for Django to be concerned
> about which formatting approach to use, apart from the immediate
> concerns of style and efficiency.

I don't think Python will ever remove %-style formatting, even in a
hypothetical "Python 4," because there are a lot of APIs (including
Django's) that expose it. Guido mentions the logging package, but
there are also a lot of third party packages that take %-style
template strings as arguments to formatting functions. As a result,
the %-style syntax will have to stick around until most of these
packages convert over, and if the latest Python 3 documentation has
even stopped recommending str.format() as a better alternative then I
expect it to stick around for good.

Best,
Alex

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

[Alex Ogier]

On Mon, Aug 20, 2012 at 3:21 PM, Alex Gaynor <alex.gay...@gmail.com> wrote:

> My inclination is that we should kill .content entirely, middleware that
> wants to rewrite the response will have two choices:
>
> 1) explicitly evaluate the entire response, and return a new HttpResponse
> object
> 2) return s anew HttpResponse object that has a generator that iteratively
> evaluates the previous one and rewrite it incrementally.
>
> Alex
>

Doesn't that break anyone who hangs arbitrary attributes on their
HttpResponse objects for the sake of their middleware? I've never done this
on the way out, only on the way in on HttpRequest objects, but I can
imagine it being useful if you wanted to conditionally disable middleware
or something. You could argue that depending on the same instance making it
through several layers of middleware is already iffy, but recommending as a
best practice to create new HttpResponses would *really* break this.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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 Check-in: Security Enhancements

[Alex Ogier]

On Tue, Jul 24, 2012 at 11:37 PM, Rohan Jain <crod...@gmail.com> wrote:
>
> I had one more idea, "Pluggable CSRF checkers".
>
> Currently, the CSRF middleware has two kinds of checks, referer (for
> https) and secret validation token (common). These with origin header
> based checker (if we add it) come in conditional blocks, making
> switching them difficult. So what I propose to do is decouple their
> logic from CSRF middleware and each of them provide a checker. It goes
> like this:
>
> A setting for configuring global CSRF checkers:
>
> CSRF_CHECKERS = {
> 'django.middleware.csrf.checkers.OriginChecker',
> # This one can be strict for https and lax for http
> 'django.middleware.csrf.checkers.RefererChecker',
> # contrib.sessions could provide a csrf checker maintained
> # with sessions. This stores the token in session data.
> 'django.contrib.sessions.csrf_checkers.SessionChecker'
> }
>

I don't think this is a good idea. If you enumerate security features
in settings.py, then later additions won't be picked up by default. If
Django add a new CSRF checking mechanism, we want everybody to take
advantage of it with no modifications.

Ordinarily I agree with you, explicit is better than implicit.
However, in the case of security features, I think this is inverted:
Django sites should be implicitly enrolled in all security mechanisms
if possible, and should be able to explicitly opt out if necessary.
Almost everyone should be using every single protection Django offers
on all their requests, and therefore it should be verbose and
discouraged to turn off these protections.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: XSS and string interpolation

[Alex Ogier]

On Thu, Jun 28, 2012 at 1:14 PM, Luke Plant <l.plant...@cantab.net> wrote:
>
> Some other alternatives: build_html, build_html_safe, format_html
>

+1 for format_html.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: XSS and string interpolation

[Alex Ogier]

On Thu, Jun 28, 2012 at 11:18 AM, Alex Ogier <alex.og...@gmail.com> wrote:
>
> Also, to be compatible with python 3 and more idiomatic python, I
> would implement the function as:
>
>    def html_mark_safe(format_string, *args):
>        return mark_safe(format_string.format(*map(conditional_escape, args)))
>

Actually, on second thought, this is even better:

def html_mark_safe(format_string, *args, **kwargs):
args_safe = map(conditional_escape, args)
kwargs_safe = dict([(k, conditional_escape(v)) for (k, v) in
kwargs.iteritems()])
return mark_safe(format_string.format(*args_safe, **kwargs_safe))

That's an HTML-safe replacement of the str.format() method, so far as
I can tell (except that all parameters must be [safe-]strings). That
allows more idiomatic python, and won't require awkward shims in
python 3, but it would mean that you can't directly translate %
interpolations. I think thats a good tradeoff.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: XSS and string interpolation

[Alex Ogier]

On Thu, Jun 28, 2012 at 10:52 AM, Jeremy Dunck <jdu...@gmail.com> wrote:
>
> On Jun 28, 2012, at 6:57 AM, Luke Plant <l.plant...@cantab.net> wrote:
>
> > Hi all,
> >
> > 2) Any better name than 'html_fragment'?
> >
>
> I like the general approach, but I miss the security-minded namse of
> "escape" and "mark safe".   Maybe "safe_html_fragment" or
> "make_safe_html_fragment"? Getting annoyingly long, I know.
>
> (Apologies if this feels bike shedding)
>

It's not just bikeshedding. The "safe" word is a good indicator that
the mark_safe utility function has been used throughout. In fact,
given the tight relationship of the two, I might even suggest a name
like "html_mark_safe," which strongly suggests "mark_safe with an html
format string."

Also, to be compatible with python 3 and more idiomatic python, I
would implement the function as:

    def html_mark_safe(format_string, *args):
return mark_safe(format_string.format(*map(conditional_escape, args)))

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: ModelForms and the Rails input handling vulnerability

[Alex Ogier]

On Jun 14, 2012 1:54 AM, "Torsten Bronger" <bron...@physik.rwth-aachen.de>
wrote:
>
> But can one guarantee that fields rendered in the browser are also
> sent back in the POST request?  Even worse, how about non-browser
> requests?
>

Ugh. I forget that checkboxes don't return anything else when they are
unchecked. Kind of throws a wrench in my plan.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: ModelForms and the Rails input handling vulnerability

[Alex Ogier]

On Jun 14, 2012 12:48 AM, "Anssi Kääriäinen" <anssi.kaariai...@thl.fi>
wrote:
>
> This seems to be different from what Rails do: they have
> update_attributes which updates all model attributes present in the
> request, but lefts all others untouched. So, in Rails if you render
> only part of the fields in update view, then you will not get the non-
> included fields overwritten to NULL, which conveniently hides the
> problem that the fields are in fact editable through the request.
>
> To me it seems there is no similar attack vector against Django's
> implementation as there were against Rails.
>

Right, the Django situation is already considerably more secure than the
Rails status quo. They have a whitelist or blacklist of attributes that
they have declared "accessible", independent of forms, making it easy to
misunderstand  that any form can update any accessible attribute regardless
of the input fields the developer has included.

Our forms only validate the fields they explicitly or implicitly include.
The only way to get a security hole is to have a mismatch between the
fields in your python form and the input fields in your HTML. Since all our
forms are explicit, it is feasible to catch that scenario and throw an
error, which I think we should do.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: ModelForms and the Rails input handling vulnerability

[Alex Ogier]

On Jun 13, 2012 8:12 PM, "Doug Blank" <doug.bl...@gmail.com> wrote:
>
> I, too, was thinking about this kind of solution. In fact, it came up
> for me the other day because I had forgotten to exclude a field that I
> did not have on the form, and so the value ended up getting wiped out
> when I saved. So, perhaps a solution that prevented others from adding
> fields could also be a solution that checked to make sure that the
> form was editing all fields it should be.
>

That suggests an idea to me. Perhaps the best way to check this isn't on
the way out in the template renderer, but rather on the way back in in the
form validation. If the form doesn't get back exactly those fields it sent
out then you know that for whatever reason, the field was unable to make a
round trip. In a ModelForm with implicit fields this is the root cause of
this whole security dilemma.

This solution is parsimonious because it's easy to explain: "If a form
didn't get back all the fields it expected then there was probably an error
of omission rendering it. This causes a security hole where an attacker can
modify fields the developer doesn't expect, for further examples see "

It's an easy thing to justify turning on in an opt-out fashion,
Meta.allow_partial_submissions or something.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: ModelForms and the Rails input handling vulnerability

[Alex Ogier]

On Tue, Jun 12, 2012 at 7:16 PM, Luke Plant <l.plant...@cantab.net> wrote:
>
> = Option 1: Leave things as they are, just document the problem. This
> was the least popular view on django-core.
>
> = Option 2: Deprecate Meta.exclude, but still allow a missing
> Meta.fields attribute to indicate that all fields should be editable.
>
> The policy here is essentially this: if any fields the model are
> sensitive, assume all are potentially, and require whitelisting, not
> blacklisting.
>
> = Option 3: Make the 'Meta.fields' attribute a required attribute, which
> must list all the model fields that should be editable. Without it,
> ModelForms would not work at all.
>
> This also means deprecating Meta.exclude (it's redundant once you are
> saying that all fields should be explicitly whitelisted).
>

What about a fourth option:

= Option 4: Make the 'Meta.fields' attribute required, but allow a
semaphore value ("__all__"?) that enables the insecure shortcut. We
can plaster it with warnings in the docs, which people will inevitably
check when the error pops up, "Meta.fields is required." There are
clearly some use cases where the maintenance burden of whitelisting
all fields is just not worth it and people will resort to hacks if we
hamstring the current behavior. It also gives an upgrade path for
people who would otherwise need to rearchitecture their applications
if the Meta.fields attribute suddenly became required. (I can imagine
models with hundreds of fields, or worse, dynamically generated
fields.)

Like Carl Meyer, I don't think Django's goals should be to protect
developers from themselves, but I agree that it is important that the
path of least resistance be secure in all areas. There is considerable
value in "A form that is automagically scaffolded from a Model" above
and beyond "A form that does default
model-field-type-to-form-field-type mappings" which is what ModelForms
will become under options 2 and 3. So long as that is an explicit
choice, I don't think there is too much harm in letting people do that
if they want to. In fact, the reason I consider Option 1 viable is
precisely because I consider the creation of a ModelForm to be
precisely that kind of choice, but I can see how having the default be
include-all is a problem.

In summary:

+0 on option 1. Making a ModelForm is already a choice to expose a
model directly.
-1 on option 2. Default is still insecure, and Meta.exclude has use cases.
+0 on option 3. It's like my option 4, but requires [for field in
Model._meta.fields] hackery to work around.
+1 on option 4. Auto-generated fields are useful, and this allows an
explicit opt-in.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: ModelForms and the Rails input handling vulnerability

[Alex Ogier]

On Tue, Jun 12, 2012 at 11:43 PM, Karen Tracey <kmtra...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 10:10 PM, Alex Ogier <alex.og...@gmail.com> wrote:
>>
>> No one can sneak extra unexpected fields past a developer by editing HTML
>> client side, because if the field wasn't rendered to HTML it's not
>> going to validate.
>
>
> But it may. If you have a template which renders specific fields, and yet
> the form is set to allow a wider set of fields than are actually rendered,
> client-side editing CAN result in the form allowing change to a field that
> had not been rendered in the template. The Django ModelForm doesn't know
> what fields were actually rendered in the HTML, it only knows what fields
> have been included/excluded from the ModelForm. You can post data for a
> field that was not rendered and it may pass validation and get saved.
>
> Karen
>

Oof, you are right. I hadn't considered the wrench that templating
throws into the works. I've always done {% for field in form.fields %}
myself, but that's a bad assumption to make.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: ModelForms and the Rails input handling vulnerability

[Alex Ogier]

you know that if it is meant to be publicly editable, you have
> to edit the ModelForms to add it, and if it is not meant to be editable,
> you don't, because the list is always "opt in".
>

I'm +1 on option 1: just keep it the way it is. The reason is that we
aren't in the same situation as Rails. We have explicit ModelForms
that conform loudly and obviously to the model. These are better than
the Rails status quo for two main reasons:

1) They are explicitly handling validation, even for implicit fields.
When you create a ModelForm you are intentionally defining a class
whose sole purpose is to manage validation of user input and pass it
to a model. It's very clear that the class sits on an untrusted
boundary, so people are less likely to say "Screw it, I'm just gonna
use the implicit scaffold my framework provides." They have to think
at least a little bit about what fields belong on their form, and if
the choice is "Everything by default" then at least it is a choice.

2) ModelForms *do* have a whitelist, in the sense that the fields they
accept in POST are exactly those fields that they generate in GET. So
far as I know no model fields other than primary keys use hidden input
widgets by default, so it's rather obvious when something changes. We
don't have the Rails problem where one dev makes a scaffold form for
an insecure model and another one adds a secure field to the model
opening up a security hole, because it's easy to notice when a
password field or top secret checkbox appears on a random form. No one
can sneak extra unexpected fields past a developer by editing HTML
client side, because if the field wasn't rendered to HTML it's not
going to validate.

My two cents.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: json vs simplejson

[Alex Ogier]

On Tue, Jun 12, 2012 at 8:49 AM, Luke Plant <l.plant...@cantab.net> wrote:
>
> I agree my existing program had a bug. I had simplejson installed
> because a dependency pulled it in (which means it can be difficult to
> get rid of).
>
> The thing I was flagging up was that the release notes say "You can
> safely change any use of django.utils.simplejson to json." I'm just
> saying the two differences I've found probably warrant at least some
> documentation.
>
> The second issue is difficult to argue as a bug in my program or
> dependencies. Django has moved from a providing a JSONEncoder object
> that supported a certain keyword argument to one that doesn't. We could
> 'fix' it to some extent:
>
> class DjangoJSONEncoder(json.JSONEncoder):
>    def __init__(self, *args, **kwargs):
>        kwargs.pop('namedtuple_as_object')
>        super(DjangoJSONEncoder, self).__init__(*args, **kwargs)
>
> But like that, it would create more problems if the json module ever
> gained that keyword argument in the future.
>

Like loads(), json.JSONEncoder is just an alias for
simplejson.JSONEncoder, and we need to support versions of simplejson
down to 1.9 which is what python 2.6 ships with. This
'namedtuple_as_object' thing seems to only appear as of simplejson
2.2, which means that depending on it is a bug that appears on any
system without a recent version of simplejson (for example, the
version that was bundled with Django doesn't support it). Depending on
this kwarg is a bug in Django, and should be fixed.

https://github.com/simplejson/simplejson/blob/namedtuple-object-gh6/simplejson/encoder.py

It's clear that people have begun to depend on the quirky ways in
which simplejson diverged from its earlier codebase. I found the place
where that unicode "proper behavior" was fixed, so apparently in
Python's stdlib they undid the C optimizations at some point. So I was
incorrect earlier, and the C speedups work "properly" with Python
stdlib's patch.

http://bugs.python.org/issue11982

Basically, anyone who depended on features of simplejson added after
1.9, or its wonky optimizations, already had arguably broken code in
that it only worked when simplejson is installed. I'm torn as to
whether we should add a note about these subtle problems when
switching to json, recommend that people switch to simplejson instead,
or undeprecate django.utils.simplejson as a necessary wart (we can
still stop vendoring simplejson though).

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: json vs simplejson

[Alex Ogier]

On Tue, Jun 12, 2012 at 7:19 AM, Luke Plant <l.plant...@cantab.net> wrote:
>
> There is another issue I found.
>
> Django's DateTimeAwareJSONEncoder now subclasses json.JSONEncoder
> instead of simplejson.JSONEncoder. The two are not perfectly compatible.
> simplejson.dumps() passes the keyword argument 'namedtuple_as_object' to
> the JSON encoder class that you pass in, but json.JSONEncoder doesn't
> accept that argument, resulting in a TypeError.
>
> So any library that uses Django's JSONEncoder subclasses, but uses
> simplejson.dumps() (either via 'import simplejson' or 'import
> django.utils.simplejson') will break. I found this already with
> django-piston.
>

Wait, 'import simplejson' works? Then that explains your problems. You
are using a library you installed yourself that has C extensions,
instead of the system json. If you switch to a system without
simplejson installed, then you should see the "proper" behavior from
django.utils.simplejson.loads(). If your program depends on some
optimized behavior of the C parser such as returning str instances
when it finds ASCII, it is bugged already on systems without
simplejson. If Django depends on optimized behavior, then it is a bug,
and a ticket should be filed.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: json vs simplejson

[Alex Ogier]

On Jun 12, 2012 6:54 AM, "Luke Plant" <l.plant...@cantab.net> wrote:
> I've found the same difference of behaviour on both a production machine
> where I'm running my app (CentOS machine, using a virtualenv, Python
> 2.7.3), and locally on my dev machine which is currently running Debian,
> using the Debian Python 2.7.2 packages.
>
> In both cases, json is always returning unicode objects, which implies I
> don't have the C extensions for the json module according to your
> analysis. I don't know enough about how this is supposed to work to
> understand why.
>

I'm not sure why no one is getting speedups from simplejson, but I can
tell you that on python 2.6+ django.utils.simplejson.loads should be
an alias for json.loads:

>>> import json
>>> json.loads('{"a":"b"}')
{u'a': u'b'}
>>> from django.utils import simplejson
>>> simplejson.loads('{"a":"b"}')
{u'a': u'b'}
>>> json.loads == simplejson.loads
True

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: json vs simplejson

[Alex Ogier]

On Mon, Jun 11, 2012 at 5:51 PM, Luke Plant  wrote:
>
> i.e. simplejson returns bytestrings if the string is ASCII (it returns
> unicode objects otherwise), while json returns unicode objects always.
>

This seemed strange to me because the standard library json shipping
with python 2.7.3 is in fact simplejson 2.0.9, so I did some digging.
It turns out that if the C extensions have been compiled and you pass
a str instance to loads(), then you get that behavior in both
versions. This isn't documented anywhere, but here's the offending
pieces:

http://hg.python.org/releasing/2.7.3/file/7bb96963d067/Modules/_json.c#l419
https://github.com/simplejson/simplejson/blob/master/simplejson/_speedups.c#L527

If the C extensions aren't enabled, or you pass a unicode string to
loads(), then you get the "proper" behavior as documented. I'm not
sure how you are triggering this optimized, iffy behavior in
django.utils.simplejson though, without also triggering it in the
standard library. Did you ever install simplejson with 'pip install
simplejson' such that Django picked it up? Can you try running 'from
django.utils import simplejson; print simplejson.__version__'?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Proposed Field API additions

[Alex Ogier]

On Thu, Jun 7, 2012 at 3:56 PM, Anssi Kääriäinen
<anssi.kaariai...@thl.fi> wrote:
> On Jun 7, 8:17 pm, Andrew Godwin <and...@aeracode.org> wrote:
>> Hi everyone,
>>
>> As part of my planning for adding schema alteration/migrations into
>> Django proper, I need to make a few changes to Fields to allow for
>> better serialisation of model definitions (pretty much a requirement for
>> any change-detecting migrations system).
>>
>> In particular, I propose:
>>
>>  - Requiring that all fields expose a method which says how to
>> reconstruct them.
>>
>> Essentially, it returns the positional and keyword arguments you would
>> have to pass into the constructor to make the field again (as there's no
>> way to get them directly). For those familiar with south_field_triple,
>> it would be a bit like that.
>
> Is the reason for this to be able to track changes to field by
> checking if its init arguments have changed? Why is it not possible to
> track changes by checking the SQL output the field will generate
> instead? This is guaranteed to be a string, and should be readily
> available for any field. I am just trying to get up to speed here...
>

This isn't particularly robust. The SQL string generated by a
particular backend isn't considered part of any API, and might change
formatting or semantics on minor updates. Some SQL is quite
complicated and dubiously related to the particular field, such as
extra INDEX or UNIQUE constraint statements. Certain backends elide
some arguments, performing constraint checking in the application (the
sqlite backend for example just drops many constraints). In general,
you want the migrations to be DB-agnostic, and checking SQL output
loses this feature.

>>  - Requiring all fields to be accessible by only their app label and
>> class name/other unique name.
>>
>> This means either having to register custom fields (like admin classes,
>> for example), or requiring fields to live in a fields.py or fields
>> package (like models and models.py). This is to provide for a
>> less-fragile way of referring to them than their full module path (which
>> might change based on project name or package location).
>
> As an idea, why not mimic the models.Model.__new__. You could have
> Field.__new__ which does the registration. A field could have
> app_label and "field name" as Meta (or just base level arguments). If
> these are not supplied, they will be generated by the __new__ from the
> field's class.__name__ and module. Once backwards compatibility period
> is over the meta variables are required.
>
> Any field which is never imported will never get registered, but I
> don't see that as a problem - if the field is not in use in the
> project, why should it need to be registered?
>

Adding additional invariants to Fields like "the (trailing module
path, ClassName) tuple must be unique over all fields" is arguably
backwards incompatible. Registering has several benefits. For example,
it doesn't impose any constraints until you decide that you want to
use migrations, at which point a nice error can be thrown: "Model Foo
has an unknown field: `field_name` of type: `project.app.CustomField`.
Please register this field with
`django.db.migrations.register_field()` before creating migrations on
the Foo model." Also, you can support third-party fields by
registering them in your own modules if you need to instead of hacking
on their code if they haven't updated it.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Django's CVB - Roadmap?

[Alex Ogier]

On Fri, Jun 1, 2012 at 3:45 PM, Iván Raskovsky <raskov...@gmail.com> wrote:
> Hi there, IMHO I think we are discussing two different topics here.
>
> The first one is documentation...
>
> The second one is the actual Generic CBV...

There's a third complaint that several people have mentioned that is
deeper than both these problems. This is that CBVs mask control flow
and this makes them inherently harder to use. Basically, since the
order of execution of your methods is an implementation detail of the
base class, everyone needs to refer to the documentation whenever they
try to examine a CBV.

This is somewhat related to the Generic CBV problem, in that a lot of
the people who ask "Why can't I do X with a Generic CBV" are really
asking, "Why isn't there a place to put what I need into the control
flow" and the answer is "Because when flow is inverted, every
extensibility point must be explicit." Adding more extensibility
points like multiple forms does nothing to fundamentally change this,
it just changes Generic CBVs from the 80% solution to the 90% solution
to the 95% solution, etc. They will never be a 100% solution,
precisely because control flow is inverted.

This problem is a really deep one, and has parallels with other
long-term sticking points in Django, such as the app model. Apps
provide a whole bunch of piecemeal functionality: some views, some
templates, some models, some tests, some urls, and these are all
executed and/or processed by Django based on its particular
implementation. For example, instead of reading the template from the
filesystem, you call a Django library function that reaches into its
global collection of loaded templates and retrieves it for you. In
CBVs, instead of calling validate() on some form, you rely on the
internals executing something for you, which makes understanding
preconditions for various methods difficult to understand without
extensive docs.

Anyways, this is a deeper problem than "There are two things we can
fix, let's get on that."

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Django git guidelines

[Alex Ogier]

On Tue, May 22, 2012 at 4:34 PM, Richard Laager <rlaa...@wiktel.com> wrote:
> On Tue, 2012-05-22 at 04:18 -0700, Anssi Kääriäinen wrote:
>> if the patch author doesn't do the final squashing, then
>> she/he will not end up as the "Author" in the commit logs.
>
> This isn't an issue. Just do:
>    git commit --author "John Doe <j...@example.com>"
>
> And if the "squash merge" workflow (which isn't something I've used)
> doesn't allow you to set the author, then just follow it by:
>    git commit --amend --author "John Doe <j...@example.com>"
>

Git actually has native support for this workflow. Each commit has an
"author" and a "committer" which are typically the same, but in the
case of a squash merge or patch are different.

For example, 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=72c04af9a2d57b7945cf3de8e71461bd80695d50

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Django git guidelines

[Alex Ogier]

I am +1 on merge --squash. The reason is that there is tremendous
value to having a mostly linear mainline development branch,
especially for one so widely depended on as Django's. My feeling is
that we should aim to have the official branches consist of only those
commits that we would feel comfortable checking out and developing
with. It is much nicer to run "git log" and see a series of focused
bug fix patches than it is to see a tangle of "Fix the reticulating
splines by frobbing the axis" "Oops, the axis was already fixed,
revert that commit" "Do the real work in hobnob.py".

In addition to making automated git bisects possible, it also lowers
the bar for contributions: so long as the code changes in a pull
request are sound, we can accept fragmented histories and badly
formatted commit messages and put the onus on the committers to clean
up commit messages for posterity.

Best,
Alex Ogier

On Fri, May 18, 2012 at 12:48 PM, Donald Stufft <donald.stu...@gmail.com> wrote:
> On Friday, May 18, 2012 at 12:30 PM, Anssi Kääriäinen wrote:
>
> On May 18, 6:08 pm, Donald Stufft <donald.stu...@gmail.com> wrote:
>
> I personally prefer doing normal merges with --no-ff. While "clean up
> whitespace"
> commits are extraneous, they don't particularly hurt anything. If an
> incoming pull
> request is particularly messy it's easy enough to say that the pull request
> is
> sound in theory/implementation but that they need to rebase it to clean up
> the history.
>
>
> While the white space commits aren't that serious, there are a couple
> of issues which need rebasing:
> - If we aim to have well formatted commit messages, any bad commit
> messages must be rewritten by changing history. Git ensures there
> isn't any other way.
> - I believe merging in broken states (code doesn't compile etc) will
> make bisecting much harder. I am not sure of this...
> - I don't find it particularly good idea to have 10 lines patches
> come in in 5 commits when just a single one is required. If you looks
> at the pull requests, you will see this is not far fetched.
>
> I think here is where it's going to come down to judgement calls. If their
> is an
> undue amount of extraneous commits for small patches then sure either
> rebasing
> or squashing probably makes sense. (Or rejecting telling the author to clean
> up their history).
>
> Commits broken for reasons other then what you are bisecting for make bisect
> a tad bit harder
> but not terribly so, basically you'd just take a peek at the log and switch
> to a nearby commit and
> test that one instead.
>
>
>
> - Anssi
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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-developers@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-developers@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: Application init inconsistent

[Alex Ogier]

My guess is that Django is doing some normalization on the name you are
importing. It does this to prevent double imports, for example importing
'projectname.appname' and 'appname' which would otherwise be considered
separate modules even if they come from the same source.

Just a theory, but it explains the behavior you are seeing if you are
importing a different name when you do the native import.

Best,
Alex Ogier
On May 7, 2012 4:34 PM, "Scott Sadler" <ssad...@mashi.org> wrote:

> Hi all,
>
> I'm making some extensions to the Django AdminSite for dashboard I'm
> working on, and I have a couple of questions. My urls.py looks
> something like this:
>
>from django.utils.importlog import import_module
>from django.contrib import admin
>
>my_admin = import_module('my.admin')
># monkeypatch admin.site so that autodiscover and subsequent
> imports reference my site instance
>admin.site = my_admin.site
>admin.autodiscover()
>
> In each application's admin.py that uses the custom extensions, I
> import the admin object directly from my.admin, so that imports wont
> break in isolation.
>
> This is only working because I do the import using import_module. If I
> do it the normal way, my site object is initialized twice; the module
> is re-imported at some point during autodiscover and the subsequent
> imports point to the wrong instance.
>
> Questions:
>
> 1: Is there a better way to extend the admin site that I'm missing? If
> not:
> 2: Shouldn't this work without hacking the import in urls.py? It took
> me a while to track this down, and it feels a bit wrong to me for the
> following reasons:
>  * It was surprising to see my site with 2 different object ids being
> generated for one __init__.py.
>  * Python supports module level mutable state, Django should respect
> that for 3rd party applications, as well as it's own.
>
> I'm also not aware of the precise reason that this is not working (why
> is the import done twice?).
>
> Thanks,
>
> Scott
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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-developers@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 quick primer on how to move feature branches to the new Git repository

[Alex Ogier]

I have posted instructions on how to easily and safely rebase feature
branches from an old fork of Django's SVN mirror onto Django's official git
repository. I hope this helps. Let me know if you need help or the
instructions are unclear or incorrect.

https://gist.github.com/2549844

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: GitHub migration planning

[Alex Ogier]

On Fri, Apr 20, 2012 at 2:58 PM, Daniel Sokolowski
<daniel.sokolow...@klinsight.com> wrote:
> Was BitBucket (mercurial system which is python based) not considered? And
> could someone point me to a url where I can read the discussion on this
> migration; I am rather curious why it’s happening – the current system works
> so I see no reason to fix it.

Well there are two somewhat related questions in play. One is moving
Django's master repository to Git from SVN. This has a lot of support,
as Git is significantly more powerful and many (most?) Django
developers already use the Git mirror.

The other debate is about switching to Github as a hosting platform.
It already hosts the Git mirror, and people regularly submit pull
requests, a feature made possible by Git and that is being considered
as an alternative to submitting patches. Github Issues are basically
unacceptable for Django's process, so they have never been seriously
considered as far as I know.

There is a large social benefit to leveraging github: there is a large
community of developers with established presences there, and making
Django accessible to that community is valuable. BitBucket does not
have the same social benefits, and all the same drawbacks, so I don't
think anyone would seriously advocate moving there.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: GitHub migration planning

[Alex Ogier]

On Thu, Apr 19, 2012 at 1:15 PM, philipn <phil...@gmail.com> wrote:
>
>
>
> On Wednesday, April 18, 2012 5:26:27 PM UTC-7, dstufft wrote:
>>
>> Github issues do not have the ability for anyone to close, tag, or create
>> milestones. You have to be the creator of the ticket or someone with
>> commit access. Django's track instance allows anyone to participate
>> in this way and is one of the major reasons to my knowledge that
>> Django will keep it's trace instance.
>>
>>
> I just investigated and it's indeed the case that non-commit members
> cannot add/delete tags or milestones from issues.  Is this a dealbreaker for
> GitHub Issues, or could this be worked around?  E.g. commit members could do
> tagging and milestone labeling.  Looking through the Trac instance, most
> milestone setting appears to be done by core devs.
>

Lack of milestones could probably be worked around, but without the
ability to tag issues Django's triage process would be dead in the
water. I don't know if Django could support that, we are up to ticket
#18xxx now. That doesn't mean there aren't ways to improve the status
quo: maybe pull requests could be supported as an explicit alternative
to attached patches. That might mean we lose explicit notification of
all code changes on a ticket.

A Trac plugin that follows changes to a GitHub pull request sounds
like a powerful tool, and could be widely useful. There's not actually
a way to notify Trac of changes to pull requests as far as I can tell,
but you can query and check for recent updates. I'll look into this
more.

As an aside, just because we are starting to use git doesn't mean that
linear history isn't valuable. I know of several successful projects
that use git that use patch-based workflows rather than merging. The
advantage of that is a linear history with each feature packaged into
a neat commit. The extra detail is great for developing, but not so
great for a mainline history (it breaks 'git bisect' for example).

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: GitHub migration planning

[Alex Ogier]

On Wed, Apr 18, 2012 at 6:46 PM, Dalton Barreto <daltonma...@gmail.com> wrote:
> Em 18 de abril de 2012 18:44, philipn <phil...@gmail.com> escreveu:
>> Hey folks!
>>
>> I started a wiki page to help plan a migration to GitHub:
>>
>> https://code.djangoproject.com/wiki/GitHub%20Migration
>>
>> I don't know what I'm doing, but I do know that the current Trac setup
>> (attaching patches, etc) is less accessible to non-core contributors than
>> GitHub and I'd love to do anything I can to help make this better.
>>
>
> Maybe the best way to avoid that people create issues on github is to
> disable it for the
> official repository. This is possible through the Github's Admin interface.
>

Err, I think the point was that Trac is less accessible than Github so
Django *should* be using Github Issues instead.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: extra files in startproject

[Alex Ogier]

On Apr 13, 2012 3:30 AM, "Luciano Pacheco" <lucm...@gmail.com> wrote:
>
> This "import django" will work even when django is not installed, because
usually "python setup.py " is ran from checkout of django, that contains
the valid folder (python package) named "django". So, this "import django"
will import relative to current directory and will work.
>

And in fact, this behavior is relied upon. Django's setup.py imports the
relative django to get the version number.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: extra files in startproject

[Alex Ogier]

On Thu, Apr 12, 2012 at 11:56 PM, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
>
> Alex Ogier <alex.og...@gmail.com> writes:
>
> > That seems like too much to ask. "setup.py install" should Just
> > Work(tm),
>
> In the absence of a proper package management system (as implemented in
> operating systems that solved this problem decades ago), you can't
> expect it to Just Work. Parallel installation of multiple versions,
> detection of previous versions, upgrade and uninstallation, dependency
> management – these are problems solved by a package manager, and
> ‘setup.py’ doesn't play well with them.
>
> Python's ‘setup.py’ can't be expected to do the job of a package
> manager, especially not in parallel to the OS which often has its own
> package manager.


The problem is that not everyone uses package managers. A reasonable
way to track django trunk for example is to periodically pull and run
"setup.py install" which is in most cases approximately idempotent. I
have seen setup.py's that use remove_tree as part of a "clean" command
to allow someone to run "setup.py clean && setup.py install" to obtain
a pristine distribution idempotently, which I think is a good idea.
The alternative is to have everyone remember to "rm -rf" their
site-packages django every time they run setup.py install which is a
bit unsavory in my opinion.

If someone has managed to get extra files in their site-packages,
because at any point they followed a tutorial on how to build from
source, then their django installation is basically caput until they
manually "rm -rf" a deep library path. One option is to document this
and explain what to do, but this really isn't very discoverable
because telling people that when django is broken, running "sudo rm
-rf" in their python site-packages might fix it is rather akin to
someone calling tech support and them asking, "Well, did you turn off
your computer and turn it on again?" It might fix the problem, but
it's invasive and time-consuming and it shouldn't be necessary.

The "real" solution to this problem is to stop treating the existence
of files as implicit indication of their inclusion in Django. That
would mean listing somewhere the files from
django/conf/project_template/ that should be included, which isn't
very DRY, but is the only 100% solution I think.

I was bit by this sort of thing a few weeks ago. I had just removed
the simplejson/__init__.py{c,} module and related code and installed a
shim at simplejson.py, all in a feature branch in git. Imagine my
surprise, upon switching to the feature branch several days later, I
found that django was using the old version. The reason was that when
I switched back to the master branch, the simplejson/__init__.pyc was
recompiled and upon checkout out the feature branch git happily
ignored all the .pyc files in my tree. Python saw them and assumed I
had a compiled version of the module and continued using them. So,
that should give you some idea of the perils of not cleaning your
output directories (or in this case, input directory).

My recommendation is to make "setup.py clean" do everything possible
to ensure idempotent installation across any version, document that,
and call it a day. Yes, Django can't make up for people who circumvent
their package manager, but we can make it a lot easier to fix than
sending newbies off into their system libraries armed with superuser
permissions and "rm -rf".

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: extra files in startproject

[Alex Ogier]

On Apr 12, 2012 6:16 PM, "Carl Meyer" <c...@oddbird.net> wrote:
>
> The correct solution is to warn people away from using installation
> techniques in ways they were not intended to be used, and that don't
> work correctly. Repeated use of "setup.py install" without removing the
> previously-installed version is inherently broken; if we work around one
> specific case where it breaks, there will be others in the future (there
> probably already are).
>

There are ways to support cleaning directories as part of the 'install'
command, for example 'distutils.dir_util.remove_tree'. Adding that for our
specific directory that needs to be clean should work, yes?

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: extra files in startproject

[Alex Ogier]

That seems like too much to ask. "setup.py install" should Just Work(tm),
and if django requires that a certain directory be clean of any .py files
in order to function properly then "setup.py install" should make that
happen. The note might still be valuable, because we should inform people
that untar-ing a version on top of another can cause problems like this,
but breaking "setup.py install" shouldn't be necessary.

If none of these are acceptable, then we can always use a different
directory (django/conf/project_template_new), so that conflicts don't
happen. It's a bit hacky but it would work.

Best,
Alex Ogier

On Thu, Apr 12, 2012 at 5:16 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 12 avr. 2012, at 21:16, Carl Meyer wrote:
>
> > The open question is just how this situation occurs in the first place.
> > In other words, which particular buggy installer or installation
> > technique is causing an overlaid installation like that, so we can warn
> > people away from it and better advise them how to fix it.
>
> This problem occurs at least when you run "setup.py install" before and
> after the commit that introduced the new project layout.
>
> Some people who had the habit of running "setup.py install" from a git
> clone to keep up-to-date with the development version reported the problem.
> (Just to be 100% clear — this technique doesn't work because it doesn't
> remove .py or .pyc files that are removed from Django.)
> As a result, I added a warning to the docs in r17636.
>
> Most likely, installing 1.4 with "setup.py install", as explained in our
> docs [1], has the same result when 1.3 was previously installed in the same
> fashion.
>
> I suggest we add a warning to this section of the docs: "if a previous
> version of Django is installed, go delete it manually in your site-packages
> directory" (unless there's a better method to remove a Python package?)
>
> Best regards,
>
> --
> Aymeric.
>
> [1]
> https://docs.djangoproject.com/en/dev/topics/install/#installing-an-official-release-manually
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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-developers@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: #18094: signals, model inheritance, and proxy models

[Alex Ogier]

I think changing when signals fire is bound to cause breakages for some
apps, and of the worst variety because signals both deal with basic data
integrity and are relatively opaque (I.e. debugging is a pain). Even if the
current behavior isn't what we would choose given a blank slate, it can't
realistically be changed.

On the other hand, supporting thus use case isn't impossible. Maybe we
could add a "fire_for_subclasses" kwarg to the connect() method or
something. That way concrete models can specify that they absolutely want
their signals fired, and the resolution can be done at load time to avoid
performance hits from isinstance calls.

Best,
Alex Ogier
On Apr 12, 2012 2:59 PM, "Carl Meyer" <c...@oddbird.net> wrote:

> On 04/12/2012 12:43 PM, Anssi Kääriäinen wrote:
> > It is important that pre/post init signals will not get more expensive
> > than they currently are. Even now they can give around 100% overhead
> > to model.__init__(). And this is in a case where the currently
> > initialized model has no signals attached at all - it is enough that
> > _some_ model in the project has pre or post init signals attached. I
> > don't believe signaling cost is severe for .save and .delete as those
> > operations are doing much heavier work than __init__ anyways, but for
> > init the cost is big enough already. If at all possible, make them
> > cheaper.
>
> So this is an argument against firing the init signals multiple times,
> for each superclass, but it's not an argument against changing the
> signal framework to include superclass receivers, as proposed in #9318;
> that would not change the performance characteristics for the
> no-receivers situation.
>
> (I see that this choice also has implications for the performance
> improvement patch in #16679, but it looks like we have a workable option
> there either way).
>
> > In addition, just changing the signals to fire for every parent class
> > is pretty much as backwards incompatible as it gets: imagine you have
> > post_save signal which increments a counter in a related model on
> > create (posts in a thread for example). You have also a proxy model,
> > and you have attached the same signal to the proxy model, too, because
> > that is what you have to do to get the signal fire when you save the
> > proxy model. After the change you will get the counter incremented two
> > times for create, and you have a data corrupting bug. This might not
> > be a common pattern, but for example Django's use of pre and post init
> > signals follows the pattern of attaching to each subclass individually
> > and these signals would thus fire multiple times.
>
> Yes, this is similar to the audit-trail handler I mentioned, and I agree
> that it is a significant backwards-compatibility problem for either option.
>
> So perhaps we do need the signal inheritance behavior to be opt-in when
> connecting the signal handler. I think I'd like to see a deprecation
> path so that eventually the inheritance behavior is the default, and you
> have to opt out of it, as I think in most cases it's the desired behavior.
>
> Carl
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: extra files in startproject (was: Django is not a serious framework, really)

[Alex Ogier]

Maybe it would be worth experimenting with various combinations of django
1.x django-admin.py executables with django 1.4 libraries? Maybe if
django-admin.py is a symlink into a 1.3 tree but django 1.4 is on the
search path this stuff could crop up?

Best,
Alex Ogier
On Apr 12, 2012 2:32 PM, "Carl Meyer" <c...@oddbird.net> wrote:

> Hi Jason,
>
> On 04/11/2012 06:10 AM, Jason Ma wrote:
> > Hi,
> > I download and tried to use the Django 1.4 yesterday. I am a dummy
> > and I just follow the official document, but When I just start a
> > project.
> > I found that it is what I see from my computer:
> >
> > jason@jason-pc:~/workspace/hunqing$ tree .
> > .
> > ├── hunqing
> > │   ├── __init__.py
> > │   ├── __init__.pyc
> > │   ├── settings.py
> > │   ├── settings.pyc
> > │   ├── urls.py
> > │   ├── urls.pyc
> > │   ├── wsgi.py
> > │   └── wsgi.pyc
> > ├── __init__.py
> > ├── manage.py
> > ├── settings.py
> > └── urls.py
> >
> > but what doc say?
> > mysite/
> > manage.py
> > mysite/
> > __init__.py
> > settings.py
> > urls.py
> > wsgi.py
>
> Others have commented on the pyc files, but I don't think that's really
> the point here. The point is that there is an extra __init__.py,
> settings.py, and urls.py in the outer directory next to manage.py that
> should not be there.
>
> This is definitely a bug, and it's one that I've already seen reported
> several times, but it is not a bug in Django. With a clean installation
> of Django 1.4, the tutorial steps work as advertised. This bug occurs if
> somehow your installation of Django 1.4 is "layered" on top of an
> installation of Django 1.3, without the 1.3 installation ever having
> been removed. I'm not sure how this happens, but my best guess is that
> it could happen if you are using a very old version of pip (like, pip
> 0.3 era, before pip gained uninstall support). You're most likely to be
> using an old pip if you are using a Linux distribution's packaged pip;
> those tend to be quite outdated.
>
> If you are interested in helping to solve this issue (as opposed to, for
> instance, trollish hyperbole), it would be very helpful to know what
> operating system and version you are using, and how you installed Django
> 1.4 (i.e the exact commands you used).
>
> Thanks!
>
> Carl
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Admin site: Appropriateness of HTTP 500 when using non-allowed query strings

[Alex Ogier]

If a query string references a foreign key that isn't in list_filter then
it can hardly be a "valid query string". This isn't an authorization
problem ("You lack permission to perform that operation"), it's a real
fatal error ("You asked us for something we don't understand/support").

>From a security standpoint, it's best to leak as little as possible about
structure and relations when you reach undefined behavior. Special-casing
this particular unhandled exception may leak information. Much better to
play dumb and handle it like every other unhandled exception.

It's not a code path you should ever reach in normal use, only when someone
is getting crafty with the admin URLs. A 400 response suggests that there
is a fixable error somewhere, and there isn't.

Best,
Alex Ogier
On Apr 11, 2012 2:44 PM, "3point2" <vasili.reve...@gmail.com> wrote:

> Julien, I'm not describing an edge case. Django will return an HTTP
> 500 for ANY field lookup on a related model that is not in the
> list_filter option.
>
> To test, simply create a model that has a ForeignKey to another model
> and hook it up into the admin site. Don't include any list_filter
> options. Then craft a valid query string on the change list page that
> queries a field on the related model. You will get an HTTP 500.
>
> For example:
>
> myapp/models.py:
>
> class MyModel(models.Model):
>parent = ForeignKey(AnotherModel)
>
> myapp/admin.py
>
> admin.site.register(MyModel)
>
> then visit http://localhost:8000/admin/myapp/mymodel/?parent__pk=1 and
> you will get a SuspiciousOperation exception with a return code of
> 500.
>
> Just to be clear, I'm not against the SuspiciousOperation exception
> being raised. I just think it should use a more appropriate HTTP
> status code, like 403.
>
>
> On Apr 11, 11:47 am, Julien Phalip <jpha...@gmail.com> wrote:
> > On Apr 10, 2012, at 4:34 AM, 3point2 wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > The admin site allows the use of certain query strings to filter
> > > change list pages. The syntax follows queryset field lookups, for
> > > examplehttp://mysite.com/admin/myapp/mymodel/?field__exact=test.
> > > Lookups that are not specified on the ModelAdmin's list_filter option
> > > raise a SuspiciousOperation exception. This is done to prevent a
> > > normal user from obtaining sensitive information (e.g. password
> > > hashes).
> >
> > > In production use, I'm not sure that returning an HTTP code of 500
> > > (internal server error) and emailing the server admins is an
> > > appropriate response to a user manipulating the query string.
> >
> > > I think that 403 (forbidden) would be more accurate. In my mind, 500
> > > suggests that something went wrong on the server, for example an
> > > unexpected condition or exception in the application code. In this
> > > situation, this is not the case. Django is deliberately forbidding a
> > > user from accessing information for which they have not been
> > > authorized.
> >
> > > Any thoughts?
> >
> > I agree that no 500 response should be returned only by passing improper
> querystring parameters, unless those parameters match a custom list filter
> and that filter raises an unhandled exception. There is already a system in
> place to avoid this problem though, so if you've found an edge case could
> you please create a new ticket in Trac with a test case?
> >
> > Thanks a lot,
> >
> > Julien
> >
> >  smime.p7s
> > 1KViewDownload
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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-developers@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: auth.user refactor: the profile aproach

[Alex Ogier]

Tai,

I think you are overestimating the importance of a "pluggable" user model.
If 100 apps all try to add fields to the User model then of course bloat
and performance issues and field name conflicts will be a problem. But I
don't think that will happen. There are very good reasons for an app *not*
to plug in: it's more work for everyone who uses your app and it means the
app is incompatible with Django's default user. I trust app developers to
recognize both of those facts.

This is orthogonal to the notion of swappable users. Django's default
doesn't satisfy many projects' needs and we want to give them a way to
implement their own user on a project-wide basis. Such users are
"pluggable" merely because they are raw python, and raw python supports
multiple inheritance and extensive monkey-patching. Setting a precedent
here is fine IMO, and doesn't signal that every app should store all data
related to the user on the user model.

Best,
Alex
On Apr 10, 2012 6:34 PM, "Tai Lee"  wrote:

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: auth.user refactor: the profile aproach

[Alex Ogier]

Tom,

I proposed mixins to solve the specific problem: there is an app that needs
a specific contract from a model it wants to authenticate or otherwise
interact with, how can we make it easy for developers to implement that
contract?

Most apps don't actually need that much though. There are a bunch of
standard ways to relate to a model that don't invasively change it. They
are all still available, and in fact preferred because no matter how easy
it is to use a mixin, doing nothing is even easier.

Best,
Alex Ogier
On Apr 10, 2012 10:58 AM, "Tom Evans" <tevans...@googlemail.com> wrote:

> On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis <ianmle...@gmail.com> wrote:
> > Hi,
> >
> > I'm not getting why you *have* to add fields to the User model to store
> data
> > pertaining to the user. There is nothing in the proposal for pluggable
> user
> > models that says you can never have a seperate model with a foreign key
> to
> > the user model. It just means that you can define your user model the way
> > you want it to be.
>
> That is perfectly fine. The problem comes when there is a simple
> system to add fields to the user model, people will use it to add
> fields to the user model in their pluggable apps, for 'simplicity' and
> 'ease of use'.
>
> > Why can't third party apps have a model with a foreign key to the user
> table
> > with the pluggable models approach? I imagine you are right that every
> app
> > and it's brother adding fields to the user model is not realistic but I
> > don't think that anyone has proposed that. Certainly not me.
>
> The proposed solution as decided by BDFL diktat is 2a from [1]. I quote:
>
> Split off as much as possible of auth.User into orthogonal mixins that
> can be reused.
> Modify auth.User to inherit these mixins. Care must be taken to ensure
> that the database expression of the new User model is identical to the
> old User model, to ensure backwards compatibility.
> Unrelated and third-party apps can indicate that they depend on
> various orthogonal mixins. For example, contrib.admin can specify that
> it works with auth.User out of the box, and with any model
> implementing PermissionsMixin if you supply your own login forms.
>
> At the moment, you cannot change the user model, so we do not have
> issues relating to third party apps changing the user model. With the
> proposed solution, you would be able to change the user model, so we
> may have issues.
>
> It's also enlightening to read the code from Alex's Django branch,
> which is an initial implementation of option 2a.
>
> > The thing I
> > want to be able to is define user models suitable for my project. Third
> > party apps adding their own fields wasn't proposed by anyone AFAIK, nor
> was
> > specifically requiring that you add them yourself. Some might require
> that
> > your user has something like an 'email' field because that would be a
> common
> > field across apps but app specific data can easily go on a seperate model
> > included with the app that simply has a FK to user. You can then only
> fetch
> > that data on requests that need it.
> >
> > I'm sorry but doing a JOIN every request is a BAD idea. You will run into
> > problems there quickly and have no way out of it besides ditching auth
> > completely (and thus all the thirdparty apps you use that depend on it).
>
> I completely disagree, but I'm not here to try and convince people how
> to design their databases. A JOIN every request will not end the
> world. Besides, it is far more likely to be a separate query than a
> JOIN, and would only happen on views that required that data.
>
> More to the point, what basis are you making this claim on? People
> love to pipe up "JOINs are slow and evil", but have you actually
> analysed the cost compared to monolithic tables?
>
> > Assuming the user table and profile tables are small is awfully short
> > sighted.
>
> To be fair, I was slightly ambiguous with my use of the word 'small'. I
> said:
>
> >> Queries against monolithic tables are much slower than a few queries on
> much
> >> smaller tables.
>
> Here 'small' means fewer columns, not less tuples.
>
> However, assuming tables will be small is precisely what you have just
> done - "we must not have JOINs, they are evil, but it doesn't matter
> because the user table will only have the columns I desire". I agree
> that it is a short sighted position, if you do not prevent the table
> becoming monolithic ;)
>
>
> Cheers
>
> Tom
>
> [1] https://code.djangoproject.com/wiki/ContribAuthImprovements
>
> --
> You received this message because yo

Re: auth.user refactor: the profile aproach

[Alex Ogier]

Hi Tom,

The best rounded description with pros and cons is Solution 2a on
https://code.djangoproject.com/wiki/ContribAuthImprovements

You are correct that I am primarily thinking of pluggable authentication
when I think of this new user model. The reason is that there is nothing
stopping you from continuing to place app data outside the user model as
has been standard for a while now. For example, there is nothing stopping
you from using the following pattern in you app's view:

if request.user.is_authenticated():
try:
prefs = GalleryPref.objects.get(user=request.user)
except GalleryPref.DoesNotExist:
prefs = None

That is, unless you have a reason that your particular data should be
eagerly loaded on every request there is no reason to require it on the
user. In fact app developers are incentivized to keep their data separate
in order to remain compatible with the default user.

The solution isn't perfect, it does in fact provide some barriers to this
pattern. The Gallery app must explicitly choose to foreign key to
settings.USER_MODEL, and once they do *changing* which model the setting
points to requires a migration of your table. These are both real issues,
but I don't think that user model bloat will be because there is a
straightforward way to work around it if it does prove to be an issue for
any particular project.

The only thing this proposal kills is magic proxying back from user
attributes. If you really wanted to, you could roll your own proxy
attributes to app fields, after all you control the entire user class.

Best,
Alex Ogier
On Apr 10, 2012 5:47 AM, "Tom Evans" <tevans...@googlemail.com> wrote:

> On Fri, Apr 6, 2012 at 7:31 PM, Alex Ogier <alex.og...@gmail.com> wrote:
> > Tai, read https://gist.github.com/2289395 for a summary of many reasons
> why
> > I think profiles are a bad idea, and unifying multiple profiles is an
> even
> > worse idea.
> >
> > Best,
> > Alex Ogier
>
> Hi Alex
>
> Is https://gist.github.com/2289395 the complete proposal for what is
> to be implemented? It seems more of a point by point rebuttal of
> another proposal.
>
> Is the approved solution to have mixins which contribute to a user
> class? Are pluggable apps expected to provide mixins that contribute
> to the user model?
>
> Does this proposal fix the current issues with the user model in new
> projects?
>
> My biggest concerns with this approach:
>
> 1) Monolithic user tables.
>
> Adding apps that want their own user storage with this system requires
> new columns in your user model. This is not the best approach. Foreign
> keys to separate user data tables per app is much more appropriate.
>
> Monolithic tables kill performance. As an example, a C++ ORM I have
> used had this approach, and it was common to come across a user table
> with 100+ columns, including some massive fields (unbounded text
> fields, blobs). On most page requests, only a few columns were looked
> at, but every page paid the cost of retrieving massive user objects.
>
> The most common complaint against profiles is that they are 'slow' as
> you have to join to many tables, or issue multiple queries. Queries
> against monolithic tables are much slower than a few queries on much
> smaller tables.
>
> 2) Constant flux on my user model as a site develops
>
> Adding new apps which require user storage would require schema
> change. If you have lots of users, this is a real pain. When adding an
> app profile, all that is required is a new table to be created, which
> would not lock a critical table like 'user' for a long period.
>
>
> I've no objection to allowing project managers more control over the
> user model, but I don't think we should encourage the majority of
> pluggable apps to pollute the user model - in fact, probably only apps
> dealing with AAA.
>
> Eg, a photo gallery app may want to store the preferred thumbnail size
> and whether to open images in a new window. These do not belong on the
> user model, but on a photo gallery app profile. Most users may not
> have preferences, and for those that do, it is only relevant to access
> that info on a photo gallery page.
>
> A twitter auth app may want to store an oauth token. This should
> belong on the user model, as it is used for AAA, and may be accessed
> on any request.
>
> Cheers
>
> Tom
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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: auth.user refactor: the profile aproach

[Alex Ogier]

Tai, read https://gist.github.com/2289395 for a summary of many reasons why
I think profiles are a bad idea, and unifying multiple profiles is an even
worse idea.

Best,
Alex Ogier

On Fri, Apr 6, 2012 at 6:15 AM, Tai Lee <real.hu...@mrmachine.net> wrote:

> Alex Ogier,
>
> Is it really better to require users to create their own User model that
> behaves like an admin user, instead of just shipping with a self contained
> admin user (as a profile model) without the auth component?
>
> If the auth app was purely a stub to connect different profiles and
> authentication systems from different apps (or the project), but doesn't
> actually define any identity or authentication or profile models itself
> (not counting base abstract classes), isn't that effectively achieving the
> separation that you want? Being able to use admin without the current cruft
> in auth or with any completely different authentication credentials, and
> similarly using any other pluggable app without any cruft needed by the
> admin.
>
> In any case, I don't think it will actually be possible to use the admin
> or any other pluggable app that relies on the concept of a central user who
> might access to multiple apps (instead of every app having its own users
> and auth) without *an* auth app and a central User model.
>
> Like Adrian, I don't actually use the User model for auth or identity
> (name, email, etc.) anymore. But unless you have authored *all* the apps in
> your project and they know how to talk to *your* User model, you still need
> a User from Django, because that is what all 3rd party pluggable apps will
> need.
>
> If I want to use any 3rd party apps that use the central user, I will
> still need to create a Django User and fake or sync the that are only there
> for the admin, even if I don't use the admin. If you still require swapped
> in User models to assume a minimal interface and fields, people will still
> have this problem.
>
> This is why I think the central User should not contain any auth or
> identity data, so there is no cruft required only for apps you may not even
> be using, and so you are not tied to any particular auth system.
>
> Cheers.
> Tai.
>
>
> On 06/04/2012, at 3:44 PM, Alex Ogier <alex.og...@gmail.com> wrote:
>
> I think this proposal will make more sense if people stop thinking "If
> someone wants to use contrib.auth, then why do we need another crufty
> interface to swap out auth.User?" Instead think of someone who wants to use
> contrib.admin but not be stuck with contrib.auth.
>
> The point of this proposal isn't to make contrib.auth larger and better,
> it's to make it unnecessary. A lot of people find contrib.auth's models
> unsatisfactory. Adrian Holovaty stated that he hasn't used auth.User for
> several years. When you have a complex site with multiple authentication
> methods and requirements that don't fit django's idea of a user, it stops
> being worth it to bend yourself to django's will. The problem is that
> contrib.auth and contrib.admin are currently intimately linked. This
> proposal's purpose is to give an official way to break these two apart.
>
> I don't know of a single framework out there besides Django that ships
> with a fixed model for its users. The reason is that authentication and
> identity are radically different for every site so it's tremendously
> important to support whatever people decide to do, and not force decisions
> on them.
>
> So, stop thinking just in terms of contrib.auth.models.User. If you're
> already using that with a profile and it's all working fine, then this
> change isn't for you. This is for everyone who just wishes auth.User would
> go away without totally borking admin.
>
> Respectfully,
> Alex Ogier
> On Apr 6, 2012 1:21 AM, "Donald Stufft" <donald.stu...@gmail.com> wrote:
>
>>  Nothing about this proposal prevents this.
>>
>> And in that case, no those 2 apps would not be able to be used together.
>> But this is hardly the first
>> time that 2 apps cannot be used together. because of choices made like
>> that on the app owner.
>>
>> On Friday, April 6, 2012 at 1:18 AM, Harris Lapiroff wrote:
>>
>> I very much share Tai's concerns about the swappable user model
>> introducing incompatibilities. Imagine two apps, each of which requires an
>> "age" attribute on the user model. But suppose one of those apps expects
>> age to be the number of years since that user's birth and one of those apps
>> expects the age to be the number of years since the user registered for the
>> website. The user model must provide the same attribute to both apps, but
>> it is supposed to have a different va

Re: auth.user refactor: the profile aproach

[Alex Ogier]

I think this proposal will make more sense if people stop thinking "If
someone wants to use contrib.auth, then why do we need another crufty
interface to swap out auth.User?" Instead think of someone who wants to use
contrib.admin but not be stuck with contrib.auth.

The point of this proposal isn't to make contrib.auth larger and better,
it's to make it unnecessary. A lot of people find contrib.auth's models
unsatisfactory. Adrian Holovaty stated that he hasn't used auth.User for
several years. When you have a complex site with multiple authentication
methods and requirements that don't fit django's idea of a user, it stops
being worth it to bend yourself to django's will. The problem is that
contrib.auth and contrib.admin are currently intimately linked. This
proposal's purpose is to give an official way to break these two apart.

I don't know of a single framework out there besides Django that ships with
a fixed model for its users. The reason is that authentication and identity
are radically different for every site so it's tremendously important to
support whatever people decide to do, and not force decisions on them.

So, stop thinking just in terms of contrib.auth.models.User. If you're
already using that with a profile and it's all working fine, then this
change isn't for you. This is for everyone who just wishes auth.User would
go away without totally borking admin.

Respectfully,
Alex Ogier
On Apr 6, 2012 1:21 AM, "Donald Stufft" <donald.stu...@gmail.com> wrote:

>  Nothing about this proposal prevents this.
>
> And in that case, no those 2 apps would not be able to be used together.
> But this is hardly the first
> time that 2 apps cannot be used together. because of choices made like
> that on the app owner.
>
> On Friday, April 6, 2012 at 1:18 AM, Harris Lapiroff wrote:
>
> I very much share Tai's concerns about the swappable user model
> introducing incompatibilities. Imagine two apps, each of which requires an
> "age" attribute on the user model. But suppose one of those apps expects
> age to be the number of years since that user's birth and one of those apps
> expects the age to be the number of years since the user registered for the
> website. The user model must provide the same attribute to both apps, but
> it is supposed to have a different value for each app. A developer will be
> unable to use these two apps together without patching one of them.
>
> A bit of a contrived example, maybe, but I can imagine this
> same-name-different-purpose issue coming up over and over again, making
> otherwise pluggable apps incompatible with each other.
>
> I think we should go with a pared down user model and allow each app to
> manage whatever data it needs on each user through profiles and signals.
> Developers will end up with some data duplication, but I think that is
> preferable to confusion about the source and purpose of data. Profiles are
> essentially a way for each app to namespace its own data and I think that's
> a good thing.
>
> Harris
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/p4jhylEp3x8J.
> To post to this group, send email to django-developers@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-developers@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-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ticket for Docs improvement Was: Proposal: upgrading the choices machinery for Django

[Alex Ogier]

> >> class User(models.Model):
> >> MALE = 0
> >> FEMALE = 1
> >> GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')]
> >> gender = models.IntegerField(choices=GENDERS)
> >>
> >> def greet(self):
> >> return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender]
> >>
>
> I' sure you meant:
>
> def greet(self):
>return {self.MALE: 'Hi, boy', self.FEMALE: 'Hi, girl.'}[self.gender]
>
> Unless you defined MALE/FEMALE as globals too :) Otherwise you'll get
> a NameError.
>
> --
> Łukasz Rekucki

As attributes of the class object I'm pretty sure they are in scope. No
NameErrors there.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: upgrading the choices machinery for Django

[Alex Ogier]

On Wed, Apr 4, 2012 at 5:18 PM, Łukasz Langa <luk...@langa.pl> wrote:

> Wiadomość napisana przez Daniel Greenfeld w dniu 4 kwi 2012, o godz. 22:48:
>
> > On two occasions now I've had to do serious debugging on implementations
> done by other people who used a technique not dissimilar to what Łukasz
> proposes. In both cases, while the inheritance and better control
> structures were nice, the issue was that if you give people enough rope to
> hang themselves, they will.
>
> Can you elaborate on that a bit? Even if the proposal is rejected in the
> end, I might use your experience to at least make the rope less deadly.


I imagine a big one is that without an explicit database representation for
every item, it is easy to get out of sync with the real data you have. And
when that happens, there isn't necessarily a good way of retrieving the
meaning of old data: if some data in your database says that you are using
license '302' but that index was implicitly auto-generated by the
particular ordering of Choice() instantiations, then when the ordering
changes you can lose track (and indexing based on an implicit ordering of
class attributes definitely seems shaky to me).

When I use enumerated fields, I generally make them VARCHAR(10) or so, and
then use plain English, potentially abbreviated, for a database
representation. That makes for reasonable code, "if self.license ==
'gpl_any':" looks very readable to me, and doesn't restrict you from
altering display values for internationalization.

It seems to me like this is really a documentation problem, where
distilling the wisdom of developers like Adrian into a little best
practices paragraph in the choices argument reference would go very far in
making the awkwardness go away.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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 2012] auth.User replacement proposal

[Alex Ogier]

Fair enough. My goal was never to shut down collaboration, and if GSoC will
do that then I am happy to drop it. The money was never my motivation, and
I will definitely still contribute what I can.

Best,
Alex Ogier

On Wed, Apr 4, 2012 at 2:46 PM, Jacob Kaplan-Moss <ja...@jacobian.org>wrote:

> On Wednesday, April 4, 2012 at 1:16 PM, Alex Ogier wrote:
>
> To Adrian specifically: You have indicated on this list that you are eager
> to have at this problem yourself, and that may make this proposal a
> non-starter. I think we are very much on the same page in terms of
> technical direction and end goals of the refactoring: I want to make this
> change as conservative as possible from a technical standpoint, but
> document, test and validate it as much as possible from the community's
> standpoint. I think we have strong motivation for the specific decisions we
> agreed on, and they give the project enough direction that it will rapidly
> become obvious if and when I am derailing your conception of what needs to
> be done, so I hope you will consider letting it be done as a GSoC project.
>
>
> The issue is specifically that GSoC does not allow collaboration -- all
> the code needs to be written by the student. There's a lot of people,
> including Adrian, who want to contribute; doing this as a GSoC project
> would actively prevent them from contributing. Auth refactoring really
> can't be a GSoC project, sorry.
>
> If you really want to work on auth, you'll need to do it outside of GSoC.
> If it's an issue of money making the difference between being able to work
> on the project and not, then let me know. We can perhaps look at taking the
> costs until the DSF's wing instead of GSoC, and thus not get into the way
> of Google's rules.
>
> 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-developers@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-developers@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 2012] auth.User replacement proposal

[Alex Ogier]

Hi folks,

I've decided to go ahead and make a GSoC proposal out of the discussion
around auth.User replacement. I'd love to contribute to this and carry
through my ideas to their conclusion, even if this proposal is shot down.

The proposal in full is at https://gist.github.com/2304321. I will continue
to keep that up to date as long as the proposal has breath left in it.

To Adrian specifically: You have indicated on this list that you are eager
to have at this problem yourself, and that may make this proposal a
non-starter. I think we are very much on the same page in terms of
technical direction and end goals of the refactoring: I want to make this
change as conservative as possible from a technical standpoint, but
document, test and validate it as much as possible from the community's
standpoint. I think we have strong motivation for the specific decisions we
agreed on, and they give the project enough direction that it will rapidly
become obvious if and when I am derailing your conception of what needs to
be done, so I hope you will consider letting it be done as a GSoC project.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: auth.user refactor: the profile aproach

[Alex Ogier]

Hi developers,

I have written up a little bit about the alternate proposal that I made a
while ago, Solution 2a from
https://code.djangoproject.com/wiki/ContribAuthImprovements

In addition to other arguments, there is a point-by-point breakdown of what
I feel are the weaknesses in Jacob's proposal.

You can find it at  https://gist.github.com/2289395

Best,
Alex Ogier

On Mon, Apr 2, 2012 at 8:35 PM, Jacob Kaplan-Moss <ja...@jacobian.org>wrote:

>  Hi folks --
>
> I've written up a proposal for how *I* would like to address refactoring
> auth.user: https://gist.github.com/2245327.
>
> In essence, this does two things:
>
> * Vastly "prunes" the required fields on auth.user. The only things left
> are an "identifier" (which could be username, email, url, uuid, whatever),
> and a password.
> * Introduces a new "profile" system that provides a way to contribute
> extra related fields. Multiple profiles are supported, along with some
> syntactic sugar for dealing with multiple profiles in a reasonably reusable
> way.
>
> And that's about it. I'm deliberately trying to find a middle ground
> between "do the minimum to allow people to move on" and "throw out and
> rewrite django.contrib.auth entirely". I'm not expecting everyone to be
> thrilled by this idea, but I'm hoping that this is "Good Enough" for almost
> everyone.
>
> For more please see the document. Please do try to read the whole thing:
> I've had a few rounds of feedback incorporated already, and there's even an
> FAQ at the end.
>
> I'm not using BDFL fiat here, at least not yet. This is a proposal, and I
> very much want to hear feedback, objections, and alternatives. I'm
> particularly interested in hearing from people who've got complicated auth
> needs and think this absolutely won't work for them.
>
> I *have* reviewed all the other proposals and I'm between -0 and -1 on all
> of them. This means that if you don't like my proposal, you'll probably
> have to come up with a complete *new* idea to have any chance of getting my
> vote.
>
> Thanks!
>
> 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-developers@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-developers@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: auth.user refactor: the profile aproach

[Alex Ogier]

On Mon, Apr 2, 2012 at 11:04 PM, Donald Stufft <donald.stu...@gmail.com>wrote:

>  Identity doesn't have anything to do with automatically dispatching
> users. All it is is a unique identifier. That's all this proposal honestly
> enforces that your users have. Some single piece of identifiable data that
> can be used to differentiate. This could be a username, or an email
> address. It could be a random string. Anything you want.
>
> In your example you might have a TwitterProfile that provides 2 fields,
> "authenticated_by_twitter" and "twitter username". Then if you want to
> check how a person authenticated to your site, you'd merely check if
> user.data["authenticated_by_twitter"] was True. The identifier doesn't need
> to have that data codified in it, (but it could!) and I honestly do not
> think the statement "all users must have 1 single string of any length that
> uniquely identifies them" is that big of a burden.
>

Perhaps I am more pessimistic than you, but I think it will quickly get out
of hand. I mean, what reasonable developer would look at the user model as
Jacob proposes, and wouldn't at least consider, "Well, I could make my own
profile and ask everyone to add my app to AUTH_PROFILES and be magically
joined on all User queries, or I could use the arbitrary length
guaranteed-unique varchar to encode a whole mess of twitter credentials. I
think I will choose option #2?"

Then as soon as everyone does that and facebook, twitter, browserid, and
plain emails all share the same namespace, we open up the same whole can of
worms that we get with cache keys, except now failures to manage things
properly manifest themselves as security holes in basic authentication
instead of cache collisions.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: auth.user refactor: the profile aproach

[Alex Ogier]

d its own table). If you really wanted to, you could make one,
and foreign-key *from* the user model which gives you everything the first
solution has, with no need to created magical .prof1, .prof2 proxy
attributes. You could even let users sign in with multiple handles with a
many-to-many. Heck, maybe your blog posts have their own twitter
credentials, I don't know.

So here's the short version of my proposal, which I plan on writing up in
full tomorrow: Break auth as it stands into reusable pieces. Let people
write their own user models, optionally using those pieces. Provide
straightforward settings for any contrib apps that absolutely *must* have a
specific model to key on (ideally none, but comments and admin probably
need shims). Document the new wave of best practices, borrowed straight
from the frameworks that got this right from the start: Write your own
user, decide what identity means (and hence, what your login forms look
like), add in whatever authentication mechanisms you like, add in whatever
authorization mechanisms you need (with specific instructions on what
contrib.admin demands from your model), and run with that.

Sorry for the rant, hopefully I'm not burning too many bridges,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Dropping django.utils.simplejson

[Alex Ogier]

I did some timing tests.
https://code.djangoproject.com/ticket/18023#comment:5

An order of magnitude difference in JSON serialization time corresponds to
an 8% change in total serialization time for a complex model, and 5 deeply
nested model instances can be serialized in < 2 ms. It might be a little
different depending on how deeply your models are related, but it convinced
me that splitting hairs over the JSON serializer isn't worth it. I had the
idea in my head that serialization might be a bottleneck in the same way
that template rendering is, but I realize now it's very different. Heavily
nested and unoptimized templates thrash the disk and change a 10ms response
into a 100ms response. Shoddy JSON serializers might thrash the heap, or
make the GC work overtime, but it's all in memory so the worst that happens
is that a 10ms response becomes a 12ms response. It's just not worth
worrying about.

Best,
Alex Ogier

On Fri, Mar 30, 2012 at 2:02 PM, Łukasz Rekucki <lreku...@gmail.com> wrote:

> On 30 March 2012 13:04, Alex Ogier <alex.og...@gmail.com> wrote:
> > At the same time, I want to reiterate my support for option #1: not
> deprecating the
> > module and leaving the shim in for the foreseeable future. If simplejson
> is
> > available on the system, and particularly if it has been compiled with C
> > extensions, then there is a significant performance gain to be had, so
> why
> > not continue to take advantage of that in all the places that django
> > serializes to json?
>
> I agree this is a valid concern and I think it should be mentioned in
> release notes. If you want more performance, then option #3 (anyjson)
> would actually be better, but I don't think it should be Django's
> concern to choose the best JSON package for you (we don't do that for
> XML). Instead, imho, Django should provide an ability to pass a custom
> JSON encode/decoder to all APIs that require it, so you can decide
> about it at the project level.
>
> --
> Łukasz Rekucki
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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-developers@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: Dropping django.utils.simplejson

[Alex Ogier]

It seems like everyone besides me agrees on option #2 so I implemented it
in #18023 <https://code.djangoproject.com/ticket/18023> (
https://github.com/ogier/django/compare/remove-simplejson ). At the same
time, I want to reiterate my support for option #1: not deprecating the
module and leaving the shim in for the foreseeable future. If simplejson is
available on the system, and particularly if it has been compiled with C
extensions, then there is a significant performance gain to be had, so why
not continue to take advantage of that in all the places that django
serializes to json?

Best,
Alex Ogier

On Fri, Mar 30, 2012 at 4:13 AM, Florian Apolloner <f.apollo...@gmail.com>wrote:

> Hi,
>
> I am for number 2 too, but don't forget that's deprecation in 1.5 and 1.6
> and removal in 1.7
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/mzYEOlCKfHkJ.
>
> To post to this group, send email to django-developers@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-developers@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: Dropping django.utils.simplejson

[Alex Ogier]

So in the process of removing simplejson I realized it's not strictly
true that we no longer need to bundle it: if someone uses 2.6+ but has
a 'json' module with a different interface sitting in front of the
system json on sys.path, then Django currently falls back to bundled
simplejson. I don't know how common that is, most alternate json
modules appear pretty inactive but you never know.

Also, whether or not that is common, it turns out there has been a bug
that looks like it was added last October that means that no one has
been using the system json module at all.

Best,
Alex Ogier

On Thu, Mar 29, 2012 at 8:10 PM, Alex Ogier <alex.og...@gmail.com> wrote:
> There's still a ~20x performance gain over 2.6's stdlib by using
> simplejson even without C-extensions according to
> http://bugs.python.org/issue6013. Depending on how heavily people
> depend on the module, removing simplejson may be a "backwards
> incompatibility" in the sense that performance may nosedive when they
> upgrade to Django 1.6. Django has always considered system-simplejson
>> system-json > vendored-simplejson. This means that in 2.6+ no one
> should be using the vendored simplejson, but the shim is still
> valuable for people who use their system's simplejson (possibly with C
> extensions) whenever available.
>
> Therefore I am in favor of option #1, unless the shim is so trivial as
> to warrant asking any developers who use it to rewrite it themselves.
>
> Best,
> Alex Ogier
>
> On Thu, Mar 29, 2012 at 7:43 PM, Russell Keith-Magee
> <russ...@keith-magee.com> wrote:
>>
>> Option 2 looks best to me. There's no reason for us to ship JSON any more, 
>> but we should still guide people through the transition process.
>>
>> Yours,
>> Russ Magee %-)
>>
>> On 30/03/2012, at 7:07 AM, Łukasz Rekucki wrote:
>>
>>> Alex's comment on ticket #18013 reminded me of this. Is there any
>>> reason not to get rid of the Django's version of simplejson now that
>>> Python 2.6 always has the json module?
>>>
>>> I see three options here:
>>>
>>> 1) Remove Django's copy and only leave the simplejson/json fallback.
>>> 2) Above, plus deprecate "django.utils.simplejson" in 1.5 and remove it 1.6
>>> 3) Replace the code with anyjson, so it does something useful:
>>> http://pypi.python.org/pypi/anyjson
>>>
>>> What do you think ?
>>>
>>> --
>>> Łukasz Rekucki
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Django developers" group.
>>> To post to this group, send email to django-developers@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-developers@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-developers@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: Dropping django.utils.simplejson

[Alex Ogier]

There's still a ~20x performance gain over 2.6's stdlib by using
simplejson even without C-extensions according to
http://bugs.python.org/issue6013. Depending on how heavily people
depend on the module, removing simplejson may be a "backwards
incompatibility" in the sense that performance may nosedive when they
upgrade to Django 1.6. Django has always considered system-simplejson
> system-json > vendored-simplejson. This means that in 2.6+ no one
should be using the vendored simplejson, but the shim is still
valuable for people who use their system's simplejson (possibly with C
extensions) whenever available.

Therefore I am in favor of option #1, unless the shim is so trivial as
to warrant asking any developers who use it to rewrite it themselves.

Best,
Alex Ogier

On Thu, Mar 29, 2012 at 7:43 PM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
>
> Option 2 looks best to me. There's no reason for us to ship JSON any more, 
> but we should still guide people through the transition process.
>
> Yours,
> Russ Magee %-)
>
> On 30/03/2012, at 7:07 AM, Łukasz Rekucki wrote:
>
>> Alex's comment on ticket #18013 reminded me of this. Is there any
>> reason not to get rid of the Django's version of simplejson now that
>> Python 2.6 always has the json module?
>>
>> I see three options here:
>>
>> 1) Remove Django's copy and only leave the simplejson/json fallback.
>> 2) Above, plus deprecate "django.utils.simplejson" in 1.5 and remove it 1.6
>> 3) Replace the code with anyjson, so it does something useful:
>> http://pypi.python.org/pypi/anyjson
>>
>> What do you think ?
>>
>> --
>> Łukasz Rekucki
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to django-developers@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-developers@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-developers@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: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

[Alex Ogier]

On Mar 29, 2012 5:43 AM, "Tai Lee" <real.hu...@mrmachine.net> wrote:
>
> I've just created an essay *cough* I mean ticket about the way Django 
> silently mangles POST data that is incorrectly encoded, and how this can send 
> someone (like me) down the rabbit hole trying to debug it, thanks to "current 
> transaction aborted" database errors.
>

This reminds me of Postel's Law, "Be conservative in what you do, be
liberal in what you accept from others." I see the reason behind your
desire to respond to this unicode error at the point of encoding, but
the issue is that there is no reasonable way for anyone to handle the
error condition. I mean, do you spit back a validation error, "Your
browser encoded the image filename in an inconsistent way. Go jump in
a ditch"? If the browser gave you a filename in a wonky encoding, a
best-effort approximation of the intended filename is the best anyone
can unless you want to send a reminder to upgrade to the latest Chrome
ve.

So the real bug here is not, "Why can't I catch and fix Unicode
problems when decoding the filename?" because you almost certainly
don't want to do that. The question is why force_encoding(...,
errors='replace') is giving you a string that PostgreSQL can't handle.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Making the EmailField RFC-compliant: proposals here!

[Alex Ogier]

On Tue, Mar 27, 2012 at 7:13 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> There's also a very recent, relatively active thread discussing our
> options with auth.User, which has a lot of overlap with this change. The
> wiki discusses all the options, and makes specific mention of the need (and
> possible migration approaches) for EmailField [1]. Given that these two
> topics are closely related, I'd rather try and keep the discussions in one
> place.
>
> [1]
> https://code.djangoproject.com/wiki/ContribAuthImprovements#Parallelconcerns
>
> Yours,
> Russ Magee %-)


Perhaps the wrong thread to ask this, but is there a way to politely
encourage a BDFL decision on the matter sooner rather than later? I would
like to submit a GSoC application around implementing the fix, and the
April 6 deadline is coming up fast. I don't know the usual timeframe on
controversial decisions like this, so if it is unlikely that a BDFL will
put their foot down significantly before the deadline then that is also
good to know. I could then apply with a looser definition of the project
contingent on an eventual decision.

Ciao,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: suggestion: Don't make the tag "url" dirty in Django1.5

[Alex Ogier]

On Mar 27, 2012 3:26 PM, "gs412" <gs...@126.com> wrote:
>
> Less symbol is the tide, the future. for example:
coffeescript、sass、haml、slim and python, there are all less symbol, this
feature make developer fell well
>
> passing context variables for tag "url" is not a good idea, it make the
work from easy to hard
>>
>> {% with url_name="client-detail-view" %}
>> {% url url_name client.id %}
>> {% endwith %}
>
>
> three lines instead of one lines, just for passing context variables,
context variables for url is not widespread
>

Well yes, it's not widespread: It's currently impossible. And it's only
three lines if you want to explicitly create a context variable inside a
template (which you will note is done with a quoted string constant). What
your example demonstrates is how to create a constant variable that is used
immediately... why would you ever do that?

Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Making the EmailField RFC-compliant: proposals here!

[Alex Ogier]

On Mar 27, 2012 8:45 AM, "Hanne Moa" <hanne@gmail.com> wrote:
>
> Let's just do it. Let's not wait for a generic migration tool! I'd
> rather the energy was spent on the app-refactor *now*, and fixing the
> email-fields *now*, which would remove some of the pressure on fixing
> the Identity/Authentication/Authorization architecture.
>

There's still several months before the 1.5 feature freeze. It's not out of
the realm of possibility that some of these summer projects will land in
1.5. Given that, I'd rather do it right.

Proper standards support for the email field is important, arguably a 1.5
release blocker, but so long as there is a good chance that migration
support will be 1.5's poster-child feature then I think email support
should be our poster child's poster child.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: make the source code of the django tutorial available ?

[Alex Ogier]

On Mon, Mar 26, 2012 at 7:28 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> Once upon a time -- way back in Django's past -- we actually did have the
> tutorial code available as part of the Django repository. The problem was
> keeping the tutorial code and the tutorial itself in sync. If the two ever
> diverged (because someone made a change and forgot to update the code) or
> if there was ever an error in the code, then anyone doing the tutorial
> would get confused -- and that's the worst possible time to get confused,
> since it's our opportunity to convince someone how good Django is.
>
> There's also the problem that the tutorial goes through 4 steps, and it
> would be useful to have the code at the end of each step of the tutorial.
> Maintaining 4 tutorial codebases is also a time consuming process.
>

There's a middle ground: add enough metadata to the tutorial that its
instructions can be interpreted by a machine. One could imagine a build
script that parses the tutorial docs and produces four templates suitable
for 1.4's project templating system, in much the way that the ALFS
project<http://www.linuxfromscratch.org/alfs/> takes
its build instructions from the Linux From Scratch documentation intended
for humans.

That said, it does seem counterproductive to give people shortcuts past the
fundamentals, especially when the fundamentals are already so carefully
curated. If you want the tutorial code as a reference, the tutorial itself
is an excellent textual description of all the changes made, so why not
just refer to that?

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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, dynamic list form field

[Alex Ogier]

Re: Facebook integration. If you want your app to go viral at all, then
requiring Facebook permissions the moment someone hits your site is going
to put a damper on things. Much better to have it only for actions that
require identity, such as adding a recipe or recommending recipes or
whatever.

Anyways, that's not actually the main point of the discussion. I think
having a field that encompasses some collection is pretty cool. I have
personally made several models in my time that were never intended to be
queried individually, but rather just had a single foreign key to a parent
model and behaved like a bag of values. The code to manipulate them ends up
everywhere: contrib.admin needs StackedInlines, forms need InlineFieldsets,
etc. even though the model is really just there to match relational
databases' notions about how data is represented. A semantic collection
that boils down to an auto-generated table would be very cool; I picture it
working something like ManyToManyFields do. The support is already in
django core for tables that serve as auto-generated intermediaries.

Once you have semantic collections as fields, all sorts of things are
possible. contrib.admin can provide inlines for free. ModelForms can
provide inlines for free. Also, the non-relational fork of Django might be
able to take advantage of them.

I second Russell's request for a better description of what you are
proposing exactly, because the concept I constructed for myself doesn't
necessarily match your conception.

-Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.