Re: Proposal: upgrading the choices machinery for Django

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

Re: auth.user refactor: the profile aproach

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

Re: Proposal: upgrading the choices machinery for Django

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

Re: auth.user refactor: the profile aproach

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

Re: Proposal: upgrading the choices machinery for Django

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

Re: auth.user refactor: the profile aproach

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.

Re: auth.user refactor: the profile aproach

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

Re: [GSoC 2012] Schema Alteration API proposal

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.

Re: Proposal: upgrading the choices machinery for Django

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

Re: auth.user refactor: the profile aproach

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

Re: [GSoC 2012] Enhanced contrib.auth

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

Re: auth.user refactor: the profile aproach

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

Re: Proposal: upgrading the choices machinery for Django

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

Re: Proposal: upgrading the choices machinery for Django

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

Re: Proposal: upgrading the choices machinery for Django

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

Re: Proposal: upgrading the choices machinery for Django

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

Re: Proposal: upgrading the choices machinery for Django

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

Re: [GSoC 2012] Enhanced contrib.auth

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

[GSoC 2012] auth.User replacement proposal

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

Re: [GSoC 2012] auth.User replacement proposal

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

Re: auth.user refactor: the profile aproach

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

Re: Proposal: upgrading the choices machinery for Django

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')), > >

Re: Proposal: upgrading the choices machinery for Django

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

Re: [GSoC 2012] Schema Alteration API proposal

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

Re: [GSoC 2012] auth.User replacement proposal

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

Re: auth.user refactor: the profile aproach

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

Re: Proposal: upgrading the choices machinery for Django

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

Re: auth.user refactor: the profile aproach

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

Re: auth.user refactor: the profile aproach

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

Re: [GSoC 2012] auth.User replacement proposal

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

Re: auth.user refactor: the profile aproach

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

Re: Proposal: upgrading the choices machinery for Django

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