I generally like this idea, except for the implicit integer ids based
on declaration order. As people have said, it seems like just asking
for data corruption. I'd much rather see implicit character ids based
on the attribute name of the choice, analogous to django fields.
Will you be making this
LazyForeignKey will not solve any problem that can't be solved now,
and we have to introduce a new concept. It sounds like, when we
encounted a hard problem, we give it a new name, instead of trying to
solve it. Moreover, to support multiple user models, each app should
be able to link to a differe
On Wednesday, April 4, 2012 at 7:19 PM, Alex Ogier wrote:
> 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.
>
>
>
Yeah, I know -- it's a r
Are we really sure that we can or should stomach a swappable User model as
a special case?
It's highly likely that I am missing something (or a few things), but
aren't the main benefits of swapping the User model just to avoid making a
backwards incompatible change, and to avoid making `select_
On 05/04/2012, at 12:20 AM, Adrian Holovaty wrote:
> On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss wrote:
>> On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote:
>>
>> My point is that there is nothing about this problem that is unique to User.
>> Django's own codebase contain
On Wed, Apr 4, 2012 at 5:18 PM, Łukasz Langa 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
On 04/04/2012, at 10:57 PM, Jacob Kaplan-Moss wrote:
> On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote:
>> My point is that there is nothing about this problem that is unique to User.
>> Django's own codebase contains another example of exactly the same pattern
>> -- Comments.
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 wrote:
> On Wednesday, April 4,
On 04/04/2012, at 11:50 PM, j4nu5 wrote:
> Hi Russell,
> Thanks for your immense patience :-)
>
> These are some additions to my proposal above, based on your inputs:
> Status of current 'creation' code in django:
> The current code, for e.g. sql_create_model in
> django.db.backends.creation is
Wiadomość napisana przez Daniel Greenfeld w dniu 4 kwi 2012, o godz. 22:48:
> +1 to what Adrian says.
Thanks for your input! :)
> 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 bo
On Wednesday, April 4, 2012 9:41:23 AM UTC-7, Adrian Holovaty wrote:
> 2012/4/3 Łukasz Langa :
> > Explicit choice values::
> >
> > GENDER_MALE = 0
> > GENDER_FEMALE = 1
> > GENDER_NOT_SPECIFIED = 2
> >
> > GENDER_CHOICES = (
> > (GENDER_MALE, _('male')),
> > (GENDER_FEMALE, _('femal
I made this in response to Jacob's original proposal, which I understand to
have been scrapped in favor of Adrian's (which doesn't have user.data at all,
thankfully).
Therefore, I believe my point below is now moot.
For the record, I am much more excited about Adrian's proposal (no offense,
Jac
I agree with Luke that more explicit is better then implicit when dealing with
the user.data.
From: Luke Sneeringer
Sent: Tuesday, April 03, 2012 2:46 PM
To: django-developers@googlegroups.com
Subject: Re: auth.user refactor: the profile aproach
So, after reading this, I think I really only ha
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
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 con
On Wed, 04 Apr 2012 19:25:26 +0300, Adrian Holovaty
wrote:
Hi Stratos,
The core team is going to take the lead on the auth.User refactoring
-- specifically, yours truly. :-)
Given that the Summer of Code policy prohibits code contributions from
non-students (right?), I don't think the User
Wiadomość napisana przez Adrian Holovaty w dniu 4 kwi 2012, o godz. 18:41:
> Also, the fact that we *don't* have a sub-framework for this lets
> people do whatever they want -- including using the dj.choices module.
> So I am -1 on including this in Django proper.
Thank you for your feedback. As
Wiadomość napisana przez Tom Evans w dniu 4 kwi 2012, o godz. 18:40:
> The class definition grates. When we say things like:
>
> class Gender(Choices):
>male = Choice("male")
>
> That says to me that Gender.male is mutable. Ick.
Thanks for your feedback. Do model and form field definitions
Wiadomość napisana przez Daniel Sokolowski w dniu 4 kwi 2012, o godz. 17:52:
> The choice filtering could come in handy and in the end I don't see why this
> can't co-exist with django's standard way.
>
> WAY 4:
Nice but very verbose.
--
Best regards,
Łukasz Langa
Senior Systems Architecture
I agree we don't really gain anything from including this in core.
Django model utils[1] has a pretty solid implementation of a choice
abstraction.
[1] https://github.com/carljm/django-model-utils
On Wed, Apr 4, 2012 at 11:41 AM, Adrian Holovaty wrote:
> 2012/4/3 Łukasz Langa :
>> Explicit choic
2012/4/3 Łukasz Langa :
> Explicit choice values::
>
> GENDER_MALE = 0
> GENDER_FEMALE = 1
> GENDER_NOT_SPECIFIED = 2
>
> GENDER_CHOICES = (
> (GENDER_MALE, _('male')),
> (GENDER_FEMALE, _('female')),
> (GENDER_NOT_SPECIFIED, _('not specified')),
> )
>
> class User(models.Model
2012/4/3 Łukasz Langa :
> A nice HTML rendering of this proposal is available at:
> http://lukasz.langa.pl/2/upgrading-choices-machinery-django/
Disclaimer: all my code currently looks like 'Way 3'.
In general, I like it. There are a few things I don't like in it:
The class definition grates. Wh
On Wed, Apr 4, 2012 at 11:22 AM, Donald Stufft wrote:
> Not adding anything, just saying that Architecture Astronaut is the best
> term ever for this.
Here's the source of that term:
http://www.joelonsoftware.com/articles/fog18.html
http://www.codinghorror.com/blog/2004/12/it-came-from-p
On Wed, Apr 4, 2012 at 10:16 AM, Stratos Moros wrote:
> I'm apologizing for replying to my own post, but there are only two days
> left before GSoC's submission deadline and my proposal has received very
> little feedback.
>
> Since other proposals about contrib.auth are being discussed, I was
> w
On Wednesday, April 4, 2012 at 12:20 PM, Adrian Holovaty wrote:
> On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss (mailto:ja...@jacobian.org)> wrote:
> > On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote:
> >
> > My point is that there is nothing about this problem that is uniqu
On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss wrote:
> On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote:
>
> My point is that there is nothing about this problem that is unique to User.
> Django's own codebase contains another example of exactly the same pattern
> -- Comments.
Hi Lukash, I'm 0 to this.
I find it well thought out but in my use cases I fail to see the advantage
over the WAY 3 (or WAY 4 pointed out below) and it adds a layer of
abstraction where a straight tuple or a list does the job well enough.
The choice filtering could come in handy and in the en
Hi Russell,
Thanks for your immense patience :-)
These are some additions to my proposal above, based on your inputs:
Status of current 'creation' code in django:
The current code, for e.g. sql_create_model in
django.db.backends.creation is a mix of *inspection* part and *sql
generation* part. Sin
Wiadomość napisana przez Thomas Guettler w dniu 4 kwi 2012, o godz. 15:55:
> since most people have something like this in their code, a better solution
> should require
> only some additional characters.
Thank you for your feedback. I disagree since it wouldn't address any of the
original conc
Hello,
I'm apologizing for replying to my own post, but there are only two days
left before GSoC's submission deadline and my proposal has received very
little feedback.
Since other proposals about contrib.auth are being discussed, I was
wondering if mine has any merit and whether I should sub
On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote:
> My point is that there is nothing about this problem that is unique to User.
> Django's own codebase contains another example of exactly the same pattern --
> Comments.
As the original author and designer of that pattern, I sho
On 04/04/2012, at 8:44 PM, Tai Lee wrote:
> I'm not so sure that it's necessary or even desirable to solve the "general"
> problem of swappable models. If anyone can swap any model by changing a
> setting, that sounds like a recipe for confusion to me.
Sure, but that's not what I've proposed.
Am 03.04.2012 21:31, schrieb Łukasz Langa:
A nice HTML rendering of this proposal is available at:
http://lukasz.langa.pl/2/upgrading-choices-machinery-django/
==
Upgrading the choices machinery for Django
==
...
Regarding swappable models:
In general, good reusable applications allow developers to substitute in their
own class or subclass for the module author's default by either a custom
setting or an argument to a method. In general, there's no reason why that
mechanism is insufficient, and should be
Wiadomość napisana przez Dan Poirier w dniu 4 kwi 2012, o godz. 14:08:
> One nice addition would be to specify explicitly what .id a particular
> Choice should have. It would be useful in converting existing code that
> might not have chosen to number its choices the same way this proposal
> does
I'm not so sure that it's necessary or even desirable to solve the
"general" problem of swappable models. If anyone can swap any model by
changing a setting, that sounds like a recipe for confusion to me.
Seems to me that the main benefit of the swappable models approach is just
to avoid backwa
I like this - it solves something that's always bugged me.
One nice addition would be to specify explicitly what .id a particular
Choice should have. It would be useful in converting existing code that
might not have chosen to number its choices the same way this proposal
does by default. It looks
django.contrib.auth.get_user already uses BACKEND_SESSION_KEY to
decide from which backend to get user object.
To support multiple user models, we can just change the
AUTHENTICATION_BACKENDS setting to a dict just as DATABASES.
AUTHENTICATION_BACKENDS = {
'default': {
'BACKEND': 'djan
38 matches
Mail list logo