Re: auth.user refactor: the profile aproach

2012-04-04 Thread bhuztez
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': 'django.contrib.auth.backends.ModelBackend',
'MODEL': 'django.contrib.auth.models.User',
},
}

Instead of a single global USER_MODEL setting, each app should have
its own USER_MODEL settings, like ADMIN_USER_MODEL,
COMMENTS_USER_MODEL .

I do not like `ForeignKey(settings.ADMIN_USER_MODEL or
settings.USER_MODEL)` . I prefer a combination of solution 2a and 2b
to that.



On 4月4日, 上午5时51分, Alex Ogier  wrote:
> Thanks for the response, Adrian.
>
> > 4. Third-party models should be changed to use something like "user =
> > UserField()", which would automatically create a foreign key to the
> > registered User model. If you change your registered User model after
> > you've created those third-party tables, you're in for trouble. Don't
> > do that.
>
> > 5. Django provides some generic APIs for getting at the registered
> > user. Example: a middleware that sets request.user based on the
> > current session.
>
> I think convenience methods are nice and all, but we should be careful of
> making "The Registered User(tm)" too much of a baked-in concept. Ian Lewis
> made a great point a few weeks ago: There are domains in which it is
> frankly inappropriate for various authenticated users to mix in the same
> database table with the same uniqueness constraints. Maybe you run a
> medical record management site, and some of your users are administrative
> staff and doctors, and some are patients. Sure, you could manage this by
> having a unified model containing everything, and carefully validating with
> an "is_doctor" field the way contrib.admin handles "is_admin," but it might
> be more appropriate to have separate models. It becomes much easier to
> express authorization constraints such as, "As a hospital administrator,
> Ms. Sally Johnson is authorized to view the patient list of Dr. John Smith,
> but *absolutely not* his record as a patient himself," or "Patients like
> Dr. John Smith can be authenticated via Facebook Connect, but doctors need
> to be authenticated via our internal LDAP." You can have login ModelForms
> for doctors that log in to doctor records and the Django admin site, and
> login ModelForms for patients that let them view their own records through
> the frontend.
>
> Obviously supporting multiple user models isn't something that should be a
> priority for Django, but locking people out of the choice seems unwise,
> when we can get the option "for free": just let authentication backends
> return any authenticated object at all to add as request.user. Python's
> duck typing will get you the rest of the way, except for those persnickety
> tables that absolutely must have a specific concrete table to foreignkey
> on. We already do something similar for AnonymousUsers, exposing a common
> interface at request.user that isn't backed up by the canonical User table.
> Generalizing that is A Good Idea in my opinion.
>
> Anyways I look forward to seeing how this progresses. I'd love to be a part
> of making this happen. Would you like me to turn my work on breaking up
> auth.User into reusable chunks into a ticket on trac? I think it makes
> sense to merge no matter what we decide on for specific settings and access
> mechanisms to developer-defined users.
>
> 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

2012-04-04 Thread Dan Poirier
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 like you could use Choices.Group(n-1) to make
the next choice defined use id=n, but that's not very elegant.

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

2012-04-04 Thread Tai Lee
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 backwards incompatibility issues by making the change opt-in, but 
I think it's also opening Pandora's box. I think that leaving it up to 
developers to ensure that their swapped-in models simply behave enough like 
the original is going to cause subtle and difficult to trace bugs.

App developers won't be able to have confidence that models they have 
defined will actually be used as defined.

This is why I would prefer to simply have an empty `User` model that is 
basically just a PK, which is used only as the glue that connects all the 
related bits and pieces (auth models, profile models, group and permissions 
models, etc.)

The rest of the existing `User` fields can be implemented in an `AdminUser` 
model, and allow multiple authentication backends, which defaults to just 
an `AdminUserBackend` authentication backend.

Apps and projects can just use this if they like, or they can define 
whatever models they like to link to the user (if they want to hook into 
other data that is linked to the user), along with their own auth backend. 
Then users can login with either admin credentials, or your project/apps 
credentials. A few abstract user base classes or auth backend classes could 
help make this part easier.

I'm not convinced that there should even be this concept (like the "data 
bag") that an app can rely on "some app" ("any app") defining a value for a 
user related field (e.g. name, email, twitter name, etc.), without knowing 
or caring which app has defined it. If you don't know which app defines the 
data, how can you know that it is the correct data for your app and your 
purpose? Likewise if you change a value, how do you know it won't 
inadvertently impact another app that relies on it? You won't know what 
other apps will be installed along side your own, what fields they will 
define, or when they will want to overwrite those fields.

There is such a thing as too generic. People can and do already define 
their own user/profile models and authentication backends. They can and do 
create their own models to store arbitrary data like name, twitter name, 
longer email address. The only problem is that there are then required and 
redundant or insufficient vestigial fields left over in `auth.User`. I have 
my own user model with username field, but I have to fake an 
`auth.User.username` to connect my user to groups and permissions. I can't 
use signals to sync my username/email address to `auth.User.email` for the 
Django admin because it's only 75 characters long and not RFC compliant.

If `auth.User` was just a glue model, with just a PK, and the other fields 
were moved to `AdminUser` (and `AdminUser.email increased in length), this 
would be a non-issue because I would not need to even have an `AdminUser` 
at all to create users for my app/project. I would only need to create one 
for users of the admin app, and in that case I should adhere to the 
AdminUser model's field requirements.

Cheers.
Tai.


On Wednesday, 4 April 2012 15:25:40 UTC+10, Eric Florenzano wrote:
>
> I completely agree with Adrian's proposal, with these amendments suggested 
> by Russell in order to build something slightly more generic, like 
> LazyForeignKey, instead of UserField.  In fact, a UserField coud end up 
> being provided as a subclass of LazyForeignKey with a default name provided 
> (e.g. 'user') and any other user-domain-specific customizations needed.
>
> Thanks,
> Eric Florenzano
>
>>

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

2012-04-04 Thread Łukasz Langa
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 by default. It looks like you could use Choices.Group(n-1) to make
> the next choice defined use id=n, but that's not very elegant.

Right. The ability to explicitly set the .id on a single choice is useful.

The only reason it's not already there is that I didn't want to write my own
`makemessages`. Then again I might do just that. My proposal is based on
a working implementation because I didn't want to fall into bikeshedding on
what could have been theoretically implemented.

What we need now to push things forward is a list of +1, +1 if ..., +0,
+0 if ..., -1, "how dare you?!" from a bunch of people.

-- 
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer

IT Infrastructure Department
Grupa Allegro Sp. z o.o.

http://lukasz.langa.pl/
+48 791 080 144

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

2012-04-04 Thread Luke Sneeringer
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 done per application.

Right now, we're trying to solve the swappable model *for User*, which is a 
bigger problem because it's not confined to a single app; it's defined in auth, 
but auth functions as a nexus for lots of other things.

Regards,
Luke

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

2012-04-04 Thread Thomas Guettler

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



since most people have something like this in their code, a better solution 
should require
only some additional characters.

GENDER_CHOICES = (
  (0, 'male'),
  (1, 'female'),
  (2, 'not specified'),
  )

# if this would be supported, updating the code would be easy
GENDER_CHOICES = Choices(
  (0, 'male'),
  (1, 'female'),
  (2, 'not specified'),
  )


#about Group
>>> class License(Choices):
  ...   COPYLEFT = Choices.Group(0)
  ...   gpl_any = Choice("GPL, any")

I don't like Choices.Group. I think it is better if choices must be set 
explicit, not
implicit (auto-increment).


Here is my solution, which is similar to way3 in your proposal.

{{{

class ChoiceDict(SortedDict):
'''
Iterating this SortedDict will return
the items (and not the keys). This is handy if
you want to uses this for a choice list on
a model field
'''
__iter__=SortedDict.iteritems

class Foo(models.Model):
STATE_NEW='new'
STATE_DONE='done'
states=ChoiceDict((STATE_NEW, _('new')),
  (STATE_DONE, _('done')),
  )
state=models.CharField(max_length=16, verbose_name=u'Status', 
default=STATE_NEU, choices=states)
}}}
I like this since, you can access the verbose string like this: 
Foo.states[obj.state]


--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

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

2012-04-04 Thread Russell Keith-Magee

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. A model would only be swappable if the 
original app developer declared that model as swappable. An end user wouldn't 
be able to arbitrarily decide that they wanted to replace a model in an app 
developed by someone else.

And sure, any feature we add could ultimately end up being used (and overused) 
in bad ways. However, that's true of any language or library feature. Classes, 
metaclasses, decorators, or any other Python language feature can be both used 
and abused, as can Django features like ModelForms or the internals of the Meta 
class. 

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. Therefore, we shouldn't pretend that the solution is User specific. 
At some point, we have to just provide enough documentation and guidance to 
shepherd people away from bad architectural decisions, and trust that the 
userbase will take that advice.

Yours,
Russ Magee %-)

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

2012-04-04 Thread Jacob Kaplan-Moss
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 should probably point 
out that I now think it's a mistake. Have you actually tried using it? It 
doesn't really work very well. Every time I've introduced any sort of 
"swappable model" mechanism I've come to regret it.

I'm -1 on the idea of generalized "swappable model" mechanism. I can stomach it 
for User because in this context it's not any worse than the alternatives, but 
as a generalized mechanism it makes me really, really unhappy. Decoupling is a 
laudable goal, but providing a mechanism to reach in and effect code not under 
your control isn't good design. We use derisive terms like "monkeypatching" for 
a reason.

I'm sure there are good reasons for wanting swappable models. Russ, I know 
you're smarter than me, so the fact that you want LazyForeignKey so much 
probably indicates that you've got some really solid use cases in mind. But 
really this is a hard veto from me; I just can't be convinced that this sort of 
mechanism is anything but bad news. 

However, I don't see why we should actively prevent this sort of thing being 
done externally, so if there's anything in Django that's precluding the 
creation of a LazyForeignKey as an external add-on let's consider that 
limitation a bug and get it fixed.

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.



Re: [GSoC 2012] Enhanced contrib.auth

2012-04-04 Thread Stratos Moros
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 submit it through 
google-melange.

Thanks.

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

2012-04-04 Thread Łukasz Langa
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 concerns from the proposal. Most importantly, reducing redundancy and 
creating a canonical place for storing information of a specific concept.

> I think it is better if choices must be set explicit, not
> implicit (auto-increment).

As Dan Poirier pointed out, setting an explicit .id on a single Choice will let 
you do that.

> Here is my solution, which is similar to way3 in your proposal.

Doesn't support groups, uses the tuple-galore syntax, still leaves you with 
redundancy of having to first define available options and later building a 
choice dictionary.

-- 
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer

IT Infrastructure Department
Grupa Allegro Sp. z o.o.

http://lukasz.langa.pl/
+48 791 080 144

-- 
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] Schema Alteration API proposal

2012-04-04 Thread j4nu5
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. Since the sql generation part will (should) now be
handled by our new CRUD API, I will refactor
django.db.backends.creation (and other backends' creation modules) to
continue using their inspection part but using our new CRUD API for
sql generation. The approach will be to get the fields using
model._meta.local_fields and feeding them to our new CRUD API. This
will serve to be a proof of concept for my API.

As for testing using Django code, my models will be something like:
class UnchangedModel(models.Model):
   eg = models.TextField()

if BEFORE_MIGRATION:
   class MyModel(models.Model):
   f1 = models.TextField()
   f2 = models.TextField()
# Deletion of a field
else:
   class MyModel(models.Model):
   f1 = models.TextField()

The value of BEFORE_MIGRATION will be controlled by the testing code.
A temporary environment variable can be used for this purpose.

Also a revised schedule:
Bonding period before GSoC: Discussion on API design
Week 1: Writing tests (using 2 part checks (checking the actual
 database and using Django models), as discussed above)
Week 2: Developing the base migration API
Week 3: Developing extensions and overrides for PostgreSQL
Weeks 4-5 : Developing extensions and overrides for MySQL
Weeks 6-7 : Developing extensions and overrides for SQLite (may be shorter 
or
  longer (by 0.5 week) depending on how much of xtrqt's 
code is
  considered acceptable)
Weeks 8-10  : Refactoring django.db backends.creation (and the PostgreSQL,
 MySQL, SQLite creation modules) to use the new API for
 SQL generation (approach discussed above)
Week 11  : Writing documentaion and leftover tests, if any
Week 12  : Buffer week for the unexpected

On Tuesday, 3 April 2012 06:39:37 UTC+5:30, Russell Keith-Magee wrote:
>
>
> On 03/04/2012, at 5:06 AM, j4nu5 wrote:
>
> > Hi Russell,
> > 
> > Thanks for the prompt reply.
> > 
> >  * You aren't ever going to eat your own dogfood. You're spending the 
> GSoC building an API that is intended for use with schema migration, but 
> you're explicitly not looking at any part of the migration process that 
> would actually use that API. How will we know that the API you build is 
> actually fit for the purpose it is intended? How do we know that the 
> requirements of "step 2" of schema migration will be met by your API? I'd 
> almost prefer to see more depth, and less breadth -- i.e., show me a fully 
> functioning schema migration stack on just one database, rather than a 
> fully functioning API on all databases that hasn't actually been shown to 
> work in practice.
> > 
> > 'Eating my own dogfood' to check whether my low level migration 
> primitives are actually *usable*, I believe can be done by:
> > 1. Developing a working fork of South to use these primitives as I 
> mentioned in my project goals, or
> > 2. Aiming for less 'breadth' and more 'depth', as you suggested.
> > 
> > I did not opt for 2, since creating the '2nd level' of the migration 
> framework (the caller of the lower level API) is a huge beast by itself. 
> Any reasonable solution will have to take care of 'Pythonic' as well as 
> 'pseudo-SQL' migrations as discussed above. Not to mention taking care of 
> versioning + dependency management + backwards migrations. I am against the 
> development of a half baked and/or inconsistent 2nd level API layer. Trying 
> to fully develop such a solution even for one database will exceed the GSoC 
> timeline, in my humble opinion.
>
> Ok - there's two problems with what you've said here:
>
>  1) You don't make any reference in your schedule to implementing a 
> "working fork of South". This isn't a trivial activity, so if you're 
> planning on doing this, you should tell use how this is factored into your 
> schedule.
>
>  2) You're making the assumption that you need to "fully develop" a 
> solution. A proof of concept would be more than adequate. For example, in 
> the 2010 GSoC, Alex Gaynor's project was split into two bits; a bunch of 
> modifications to the core query engine, and a completely separate project, 
> not intended for merging to trunk, that demonstrated that his core query 
> changes would do what was necessary. You could take exactly the same 
> approach here; don't try to delivery a fully functioning schema migration 
> tool, just enough of a tool to demonstrate that your API is sufficient. 
>
> >  * It feels like there's a lot of padding in your schedule.
> > 
> >- A week of discussion at the start
> >- 2 weeks for a "base" migration API
> >- 2.5 weeks to write documentation
> >- 2 "buffer" weeks
> > 
> > Your pro

Re: Proposal: upgrading the choices machinery for Django

2012-04-04 Thread Daniel Sokolowski

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 end I don't see why this 
can't co-exist with django's standard way.


WAY 4:

class UserManager(models.Manager):
   GENDER_MALE = 0
   GENDER_FEMALE = 1
   GENDER_NOT_SPECIFIED = 2
   GENDER_CHOICES = (
   (GENDER_MALE, _('male')),
   (GENDER_FEMALE, _('female')),
   (GENDER_NOT_SPECIFIED, _('not specified')),
   )

   def males(self):
   """ Returns all entries accessible through front end site"""
   return self.all().filter(gender=self.GENDER_MALE)
   def females(self):
   """ Returns all entries accessible through front end site"""
   return self.all().filter(gender=self.GENDER_FEMALE)
   ...

class User(models.Model):
   gender = models.IntegerField(choices=UserManager.GENDER_CHOICES,
   default=UserManager.GENDER_NOT_SPECIFIED)
   objects = UserManager()

   ef greet(self):
   if self.gender == UserManager.GENDER_MALE:
   return 'Hi, boy.'
   elif self.gender == UserManager.GENDER_NOT_SPECIFIED:
   return 'Hello, girl.'
   else: return 'Hey there, user!'

-Original Message- 
From: Łukasz Langa

Sent: Wednesday, April 04, 2012 9:15 AM
To: django-developers@googlegroups.com
Subject: 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 by default. It looks like you could use Choices.Group(n-1) to make
the next choice defined use id=n, but that's not very elegant.


Right. The ability to explicitly set the .id on a single choice is useful.

The only reason it's not already there is that I didn't want to write my own
`makemessages`. Then again I might do just that. My proposal is based on
a working implementation because I didn't want to fall into bikeshedding on
what could have been theoretically implemented.

What we need now to push things forward is a list of +1, +1 if ..., +0,
+0 if ..., -1, "how dare you?!" from a bunch of people.

--
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer

IT Infrastructure Department
Grupa Allegro Sp. z o.o.

http://lukasz.langa.pl/
+48 791 080 144

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

2012-04-04 Thread Adrian Holovaty
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.
>
> As the original author and designer of that pattern, I should probably point
> out that I now think it's a mistake. Have you actually tried using it? It
> doesn't really work very well. Every time I've introduced any sort of
> "swappable model" mechanism I've come to regret it.

Totally agree with Jacob here, plus Tai's comment that "There is such
a thing as too generic." We've made the mistake of making things too
generic in the past, and it's kind of infuriating in retrospect, both
philosophically and in terms of code maintenance/understanding.
(django/utils/tree.py, anyone??)

I think our policy should be: make the simplest thing that can
possibly work for a narrowly-tailored use case, then make things more
generic *slowly* if there's a demand. No need to be an Architecture
Astronaut.

Adrian

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

2012-04-04 Thread Donald Stufft
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 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 should probably point
> > out that I now think it's a mistake. Have you actually tried using it? It
> > doesn't really work very well. Every time I've introduced any sort of
> > "swappable model" mechanism I've come to regret it.
> > 
> 
> 
> Totally agree with Jacob here, plus Tai's comment that "There is such
> a thing as too generic." We've made the mistake of making things too
> generic in the past, and it's kind of infuriating in retrospect, both
> philosophically and in terms of code maintenance/understanding.
> (django/utils/tree.py, anyone??)
> 
> I think our policy should be: make the simplest thing that can
> possibly work for a narrowly-tailored use case, then make things more
> generic *slowly* if there's a demand. No need to be an Architecture
> Astronaut.
> 
> 

Not adding anything, just saying that Architecture Astronaut is the best term 
ever for this. 
> 
> Adrian
> 
> -- 
> 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 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto: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: [GSoC 2012] Enhanced contrib.auth

2012-04-04 Thread Adrian Holovaty
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
> wondering if mine has any merit and whether I should submit it through
> google-melange.

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 refactoring would work
as a Summer of Code project. Sorry to break this news, as you've
clearly done a lot of preparation and thinking about the issue, but of
course we'd love to have you contribute to this particular feature
*outside* the Summer of Code.

Adrian

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

2012-04-04 Thread Adrian Holovaty
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-planet-architecture.html

Adrian

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

2012-04-04 Thread Tom Evans
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. When we say things like:

  class Gender(Choices):
male = Choice("male")

That says to me that Gender.male is mutable. Ick.


There is no easy way by inspecting the code to see what choice a value
of 7 equates to any-more. Do the choices start from 0 or do they start
from 1, as inferred by the examples (Why? What is wrong with 0?).
Repetition isn't good, but ambiguity is worse.


I don't like the grouping at all. Grouping under the old system was
clean and simple, it didn't require magic arguments, groups didn't
require that all options are contiguous in a single range.

This grouping system just seems destined for data loss/confusion. If I
want to split a group in two, the enums in the new group change
values! That is not a good approach, and was not necessary with the
old system.

This grouping system cannot logically arrange the options into groups,
since it relies on them being attributes of the class, and so you need
to invent a way of grouping. If I had a vote, I'd be strongly -1 on
any proposal with this sort of grouping, it seems dangerous and wrong.


Finally, the proposal seems to concentrate solely on choices as an
enum. The proposal completely ignores that choices can be almost any
kind of value, eg:

MALE="m"
FEMALE="f"
UNKNOWN="?"
GENDER_CHOICES = (
(MALE, "Male"),
(FEMALE, "Female"),
(UNKNOWN, "Unknown"),
  )

this would be an entirely appropriate choices for a CharField.

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: Proposal: upgrading the choices machinery for Django

2012-04-04 Thread Adrian Holovaty
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):
>      gender = models.IntegerField(choices=GENDER_CHOICES,
>              default=GENDER_NOT_SPECIFIED)
>
>      def greet(self):
>          if self.gender == GENDER_MALE:
>              return 'Hi, boy.'
>          elif self.gender == GENDER_NOT_SPECIFIED:
>              return 'Hello, girl.'
>          else: return 'Hey there, user!'
>
> This is a saner way but starts getting overly verbose and redundant. You can
> improve encapsulation by moving the choices into the ``User`` class but that 
> on
> the other hand beats reusability.

I don't see the immediate need for Yet Another Sub-framework, as
described in this proposal. This is what I normally do, and it works
fine:

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]

If people aren't understanding that, we should improve our documentation.

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.

Adrian

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

2012-04-04 Thread Sean Brant
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 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):
>>      gender = models.IntegerField(choices=GENDER_CHOICES,
>>              default=GENDER_NOT_SPECIFIED)
>>
>>      def greet(self):
>>          if self.gender == GENDER_MALE:
>>              return 'Hi, boy.'
>>          elif self.gender == GENDER_NOT_SPECIFIED:
>>              return 'Hello, girl.'
>>          else: return 'Hey there, user!'
>>
>> This is a saner way but starts getting overly verbose and redundant. You can
>> improve encapsulation by moving the choices into the ``User`` class but that 
>> on
>> the other hand beats reusability.
>
> I don't see the immediate need for Yet Another Sub-framework, as
> described in this proposal. This is what I normally do, and it works
> fine:
>
> 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]
>
> If people aren't understanding that, we should improve our documentation.
>
> 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.
>
> Adrian
>
> --
> 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: Proposal: upgrading the choices machinery for Django

2012-04-04 Thread Łukasz Langa
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 Engineer

IT Infrastructure Department
Grupa Allegro Sp. z o.o.

http://lukasz.langa.pl/
+48 791 080 144

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

2012-04-04 Thread Łukasz Langa
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 say that as well? 
It's true that I could have block users from mutating the value but "we're all 
consenting adults here", right?

> There is no easy way by inspecting the code to see what choice a value
> of 7 equates to any-more.

True, the same goes for spotting errors with manual numbering when there are 
many values.

> Do the choices start from 0 or do they start
> from 1, as inferred by the examples (Why? What is wrong with 0?).
> Repetition isn't good, but ambiguity is worse.

It's a matter of aesthetics and as such it's totally subjective. I made the 
values start from 1 so that the first Choice.Group can have value 0 and not -1 
which looks ugly.

> This grouping system just seems destined for data loss/confusion. If I
> want to split a group in two, the enums in the new group change
> values! That is not a good approach, and was not necessary with the
> old system.

I can't see how they have to.

> If I had a vote, I'd be strongly -1 on
> any proposal with this sort of grouping, it seems dangerous and wrong.

Can you elaborate on what is dangerous about them?

> Finally, the proposal seems to concentrate solely on choices as an
> enum. The proposal completely ignores that choices can be almost any
> kind of value, eg:
> 
> MALE="m"
> FEMALE="f"
> UNKNOWN="?"
> GENDER_CHOICES = (
>(MALE, "Male"),
>(FEMALE, "Female"),
>(UNKNOWN, "Unknown"),
>  )
> 
> this would be an entirely appropriate choices for a CharField.

Using code in my proposal:

>>> class Gender(Choices):
... m = Choice("male")
... f = Choice("female")
... n = Choice("not specified")
... 
>>> Gender(item=lambda c: (c.name, c.desc))
[(u'm', u'male'), (u'f', u'female'), (u'n', u'not specified')]

-- 
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer

IT Infrastructure Department
Grupa Allegro Sp. z o.o.

http://lukasz.langa.pl/
+48 791 080 144

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

2012-04-04 Thread Łukasz Langa
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 you're one of the BFDLs for the project, that 
basically closes the proposal as rejected, am I right?

-- 
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer

IT Infrastructure Department
Grupa Allegro Sp. z o.o.

http://lukasz.langa.pl/
+48 791 080 144

-- 
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] Enhanced contrib.auth

2012-04-04 Thread Stratos Moros
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 refactoring would work
as a Summer of Code project. Sorry to break this news, as you've
clearly done a lot of preparation and thinking about the issue, but of
course we'd love to have you contribute to this particular feature
*outside* the Summer of Code.

Adrian



Ok. I'd love to contribute either way.

Thanks for the info.

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

2012-04-04 Thread 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: [GSoC 2012] auth.User replacement proposal

2012-04-04 Thread Jacob Kaplan-Moss
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.



Re: auth.user refactor: the profile aproach

2012-04-04 Thread Daniel Sokolowski
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 have a couple questions/concerns:

1. What, if anything, is the primary key on the base User model? Is it the 
identifier? If so, can it be specified as the primary key, rather than 
unique=True, db_index=True? If it's not the primary key, is it the usual 
magical id = models.AutoField()?

2. I'm a little nervous about the magical installation of Profile modules -- 
specifically, what happens once this system has been around for one to two 
years and we have a ton of these? I'm imagining a situation where there are 
lots of apps floating around, each with their own Profile subclasses that 
install behind the scenes when you install the app (and which you may or may 
not actually realize up front -- yes, a good developer *should* be aware of 
that, but that doesn't mean they will be...). What happens if a beginner writes 
everything against user.data['name'], and then installs an app that adds a new 
name, which is unordered and magically ends up on top, and therefore introduces 
new, unexpected, and, most importantly, extremely difficult to debug logic 
errors?

I agree with some of the criticisms of swappable user models, but at least the 
developer always knows what he is doing in that case. In this case, the 
behavior of your user model can change in unexpected ways when you do something 
that seems totally unrelated; some code that previously worked might either (1) 
return different data or (2) suddenly raise KeyError.

Perhaps this is the best of bad options. I agree there's a decent bit to be 
argued in favor of it, but can we figure out a less error-prone way for 
user.data to work? Honestly, I think it would be less risky to force everyone 
to write user.admin_profile.name -- it's more typing, but at least it's 
explicit. The current proposal for user.data doesn't actually pass "refuse the 
temptation to guess", because it glosses over the fact that developers *will 
guess* and then their code will stop working after what feels like a completely 
unrelated change.

3. Might I suggest that the Profile model that the admin requires be called 
AdminProfile and not DefaultProfile? It's really an admin need more than 
anything else.


Best Regard,
Luke



On April 2, 2012, at 19:35 , Jacob Kaplan-Moss 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.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to

Re: auth.user refactor: the profile aproach

2012-04-04 Thread Luke Sneeringer
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, 
Jacob :)). I was convinced that profiles was the only way to go when I read 
Jacob's proposal, but it sounds like there is a mechanism to make swappable 
User models work, which is much more in tune with how I use Django. Profiles, 
to me, are ugly. At best.

Regards,
Luke

On April 4, 2012, at 15:28 , Daniel Sokolowski wrote:

> 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 have a couple 
> questions/concerns:
>  
> 1. What, if anything, is the primary key on the base User model? Is it the 
> identifier? If so, can it be specified as the primary key, rather than 
> unique=True, db_index=True? If it's not the primary key, is it the usual 
> magical id = models.AutoField()?
>  
> 2. I'm a little nervous about the magical installation of Profile modules -- 
> specifically, what happens once this system has been around for one to two 
> years and we have a ton of these? I'm imagining a situation where there are 
> lots of apps floating around, each with their own Profile subclasses that 
> install behind the scenes when you install the app (and which you may or may 
> not actually realize up front -- yes, a good developer *should* be aware of 
> that, but that doesn't mean they will be...). What happens if a beginner 
> writes everything against user.data['name'], and then installs an app that 
> adds a new name, which is unordered and magically ends up on top, and 
> therefore introduces new, unexpected, and, most importantly, extremely 
> difficult to debug logic errors?
>  
> I agree with some of the criticisms of swappable user models, but at least 
> the developer always knows what he is doing in that case. In this case, the 
> behavior of your user model can change in unexpected ways when you do 
> something that seems totally unrelated; some code that previously worked 
> might either (1) return different data or (2) suddenly raise KeyError.
>  
> Perhaps this is the best of bad options. I agree there's a decent bit to be 
> argued in favor of it, but can we figure out a less error-prone way for 
> user.data to work? Honestly, I think it would be less risky to force everyone 
> to write user.admin_profile.name -- it's more typing, but at least it's 
> explicit. The current proposal for user.data doesn't actually pass "refuse 
> the temptation to guess", because it glosses over the fact that developers 
> *will guess* and then their code will stop working after what feels like a 
> completely unrelated change.
>  
> 3. Might I suggest that the Profile model that the admin requires be called 
> AdminProfile and not DefaultProfile? It's really an admin need more than 
> anything else.
>  
>  
> Best Regard,
> Luke

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

2012-04-04 Thread Daniel Greenfeld
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, _('female')),
> >  (GENDER_NOT_SPECIFIED, _('not specified')),
> >  )
> >
> >  class User(models.Model):
> >  gender = models.IntegerField(choices=GENDER_CHOICES,
> >  default=GENDER_NOT_SPECIFIED)
> >
> >  def greet(self):
> >  if self.gender == GENDER_MALE:
> >  return 'Hi, boy.'
> >  elif self.gender == GENDER_NOT_SPECIFIED:
> >  return 'Hello, girl.'
> >  else: return 'Hey there, user!'
> >
> > This is a saner way but starts getting overly verbose and redundant. You 
> can
> > improve encapsulation by moving the choices into the ``User`` class but 
> that on
> > the other hand beats reusability.
>
> I don't see the immediate need for Yet Another Sub-framework, as
> described in this proposal. This is what I normally do, and it works
> fine:
>
> 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]
>
> If people aren't understanding that, we should improve our documentation.
>
> 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.
>
> Adrian
>


+1 to what Adrian says. In fact...

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.

The current system works very well, especially when you follow Adrian's 
pattern. Lukasz' system works well too. Therefore...

I submit that we keep Django core for choices as is and let people who want 
to use another system implement 3rd party packages. 
 

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

2012-04-04 Thread Łukasz Langa
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 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.

-- 
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer

IT Infrastructure Department
Grupa Allegro Sp. z o.o.

http://lukasz.langa.pl/
+48 791 080 144

-- 
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] Schema Alteration API proposal

2012-04-04 Thread Russell Keith-Magee

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 a mix of *inspection* part and *sql
> generation* part. Since the sql generation part will (should) now be
> handled by our new CRUD API, I will refactor
> django.db.backends.creation (and other backends' creation modules) to
> continue using their inspection part but using our new CRUD API for
> sql generation. The approach will be to get the fields using
> model._meta.local_fields and feeding them to our new CRUD API. This
> will serve to be a proof of concept for my API.

Hrm - not exactly ideal, but better than nothing I suppose. Ideally, there 
would actually be some migration task involved in your proof of concept.

> As for testing using Django code, my models will be something like:
> class UnchangedModel(models.Model):
>eg = models.TextField()
> 
> if BEFORE_MIGRATION:
>class MyModel(models.Model):
>f1 = models.TextField()
>f2 = models.TextField()
> # Deletion of a field
> else:
>class MyModel(models.Model):
>f1 = models.TextField()
> 
> The value of BEFORE_MIGRATION will be controlled by the testing code.
> A temporary environment variable can be used for this purpose.

Unless your plan also includes writing a lot of extra code to purge and 
repopulate the app cache, this approach won't work. Just changing a setting 
doesn't change the class that has already been parsed and processed.


> Also a revised schedule:
> Bonding period before GSoC: Discussion on API design
> Week 1: Writing tests (using 2 part checks (checking the actual
>  database and using Django models), as discussed above)
> Week 2: Developing the base migration API
> Week 3: Developing extensions and overrides for PostgreSQL
> Weeks 4-5 : Developing extensions and overrides for MySQL
> Weeks 6-7 : Developing extensions and overrides for SQLite (may be shorter or
>   longer (by 0.5 week) depending on how much of xtrqt's code 
> is
>   considered acceptable)
> Weeks 8-10  : Refactoring django.db backends.creation (and the PostgreSQL,
>  MySQL, SQLite creation modules) to use the new API for
>  SQL generation (approach discussed above)
> Week 11  : Writing documentaion and leftover tests, if any
> Week 12  : Buffer week for the unexpected
> 

This looks a bit more convincing.

Yours,
Russ Magee %-)

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

2012-04-04 Thread 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 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.



Re: auth.user refactor: the profile aproach

2012-04-04 Thread Russell Keith-Magee

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.
> As the original author and designer of that pattern, I should probably point 
> out that I now think it's a mistake. Have you actually tried using it? It 
> doesn't really work very well. Every time I've introduced any sort of 
> "swappable model" mechanism I've come to regret it.
> 
> I'm -1 on the idea of generalized "swappable model" mechanism. I can stomach 
> it for User because in this context it's not any worse than the alternatives, 
> but as a generalized mechanism it makes me really, really unhappy. Decoupling 
> is a laudable goal, but providing a mechanism to reach in and effect code not 
> under your control isn't good design. We use derisive terms like 
> "monkeypatching" for a reason.

Agreed that monkeypatching is bad. However, I think that's the wrong analogy in 
this case; I think "interface" is a closer match.

An interface is essentially just a way of saying "I need to operate on an 
object with these properties, but I'm going to let the end user define the 
specific object instance that provides those properties". As a language, Python 
generally doesn't need interfaces because of duck typing. However, ForeignKey 
is a "strongly typed" database relationship, so you can't duck type it -- the 
original app developer needs to be able to define it as something that the end 
developer might want to change.

> I'm sure there are good reasons for wanting swappable models. Russ, I know 
> you're smarter than me,

Don't put too much weight in that argument. I have plenty of braindead ideas. 
The PhD just means I'm persistent :-)

> so the fact that you want LazyForeignKey so much probably indicates that 
> you've got some really solid use cases in mind. But really this is a hard 
> veto from me; I just can't be convinced that this sort of mechanism is 
> anything but bad news. 

To tell the truth, I haven't used the comments app extensively, so I can't 
really comment on that example specifically. I also don't have a specific case 
in mind where I want to use this feature. However, if you think of the problem 
being solved here as interfaces, it isn't hard to think of other possible 
applications.

More broadly, my reaction comes from the the fact that I *have* been bitten -- 
many times -- by claims that "this is a special case". Special cases almost 
never are, and the counterexample usually shows up a week after you're 
irretrievably committed to a "specialized" solution. 

> However, I don't see why we should actively prevent this sort of thing being 
> done externally, so if there's anything in Django that's precluding the 
> creation of a LazyForeignKey as an external add-on let's consider that 
> limitation a bug and get it fixed.

Sure -- I can live with that. There's really only two places where I see this 
being an issue in practice:

 1) Introducing UserField(). I'd be against introducing UserField() as a 
special case of ForeignKey(). Even though it's more typing, 
ForeignKey(settings.USER_MODEL) offends me less. This doesn't preclude other 
developers writing their own ForeignKey shortcuts; I just think it sets a bad 
example.
 
 2) The synchronization/app cache problem. In order to do this properly, we 
need to prevent the auth_user table from being created, and auth.User being 
added to the app cache. If we're going to address this by adding hooks into the 
model startup process, I'd like to see them as general hooks, rather than 
special cases for auth.User -- even if they're undocumented hooks.

Of course, the other option is just an if statement in the models.py file:

if settings.USER_MODEL == 'auth.User':
class User(models.Model):
username = ...

which is a pattern that other uses could adopt.

Yours,
Russ Magee %-)


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

2012-04-04 Thread Alex Ogier
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 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: auth.user refactor: the profile aproach

2012-04-04 Thread Russell Keith-Magee

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 contains another example of exactly the same pattern
>> -- Comments.
>> 
>> As the original author and designer of that pattern, I should probably point
>> out that I now think it's a mistake. Have you actually tried using it? It
>> doesn't really work very well. Every time I've introduced any sort of
>> "swappable model" mechanism I've come to regret it.
> 
> Totally agree with Jacob here, plus Tai's comment that "There is such
> a thing as too generic." We've made the mistake of making things too
> generic in the past, and it's kind of infuriating in retrospect, both
> philosophically and in terms of code maintenance/understanding.
> (django/utils/tree.py, anyone??)
> 
> I think our policy should be: make the simplest thing that can
> possibly work for a narrowly-tailored use case, then make things more
> generic *slowly* if there's a demand. No need to be an Architecture
> Astronaut.

Certainly agreed that astronauting is a bad thing. 

However, I would like to draw attention to one particular benefit of the 
generic solution (other than being generic):

Once we make User swappable, every app with a model that has a ForeignKey to 
User will need to be updated. This can be done slowly; existing projects that 
use auth.User will continue to work. However there won't be any real alert to 
the fact that the app requires updating until you try to swap out User and 
things start to break. This breakage will be somewhat unpredictable -- you'll 
just be observing side effect errors as a result of a non-existent (or empty) 
auth_user table.

Under the approach I described, User will be marked (in the Meta object) as 
swappable, and ForeignKey(User) will be a hard link to a swapapble model, which 
is something we can catch as a validation warning, providing a cue to 
developers that there are apps in their project that may need to be updated. 
And if there is a ForeignKey(User) and settings.USER_MODEL *isn't* User, then 
we can raise an validation error, because we know that this app won't work.

Even if we don't implement a fully generic solution, I think this property of 
the generic approach is worth preserving.

Yours,
Russ Magee %-)

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

2012-04-04 Thread Tai Lee
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_related()` 
queries?

I'm not suggesting that backwards incompatibility is not important, but I'm 
not convinced by the argument about inefficient `select_related()` queries, 
and whatever we do will involve manual schema migration for many users.

Do we really need to allow users to swap in their own model with a 
combination of additional project level fields as well as additional fields 
required by various pluggable apps as the primary `User` model, instead of 
simply stripping out authentication and identifying fields from the primary 
`User` model and allowing users to implement whatever they need as app or 
project level profile models?

The more I think about it, the more I think this will just lead to more 
fragmentation and incompatibilities with pluggable apps, when the user 
"interface" is abused or causes conflicts.

What's going to happen when this is rolled out and people start developing 
an eco-system of pluggable apps without a concrete `User` model in Django? 
All they can rely on is that there will be some form of `User` model and 
that it *should* provide at least a minimal set of fields and behaviours as 
specified by some guidelines in Django docs?

Won't we just be back at square 1 in deciding what to include in the 
minimal fields and guidelines for the this "contract"? Isn't the only 
sensible minimal set of fields, no fields at all?

Pluggable apps will have to either dictate to developers in the 
installation instructions that their particular `User` model must have 
certain fields or behaviours that are required by the pluggable app, which 
may even conflict with other pluggable apps. Or they will still have to 
fallback to using an app-profile model, which brings us back to using 
`select_related()` anyway. I don't like the idea that a pluggable app might 
require users to change their existing models like this.

If pluggable apps will still need to use app-profile models anyway, if we 
can get past the backwards incompatibility issue, what is so bad about 
simply having a `User` model which has no auth or identity data in it, but 
is just there as glue for for apps to share data for a single "user"?

Bundled apps like the admin would define `AdminProfile` and any pluggable 
apps that require or support the admin could access `user.admin_profile`. 
Pluggable apps that don't use the admin and/or have their own auth or 
identifying requirements can just ship with their own profile and/or auth 
models and optional auth backend.

The only real issue I have with Django users/auth as it is right now is 
that there are redundant (for me) or non-compliant (with RFC) fields in 
`auth.User` that are required and that I have to fake in order to hook into 
the admin, groups and permissions or re-specify in my own profile for 
RFC-compliance.

The other problem I have seen mentioned with the profile approach is 
managing common fields (e.g. two pluggable apps that have a "name" field). 
I'm quite happy for this to be managed by the developer at a project level, 
either using signals or forms or a `save()` method on their profile model 
or whatever else they like to keep that data in sync, if it needs to be 
kept in sync.

I don't think pluggable apps requiring that developers have a "name" (for 
example) field on their primary `User` model is really a good solution to 
this problem, because the pluggable app doesn't know what other purpose 
that field is used for, and doesn't know if it is changed in app1 if it 
will have any consequences for app2.

If developers really want a single project level `User` model, they can 
still create that (with an FK back to Django's `User` model), and simply 
update it's `save()` method to sync any common fields on all the pluggable 
app's profile models (which may even have different field names). E.g. 
`project.User` could have `first_name` and `last_name`, but app1 has only 
`name`, and app2 has `given_name` and `family_name`. In 
`project.User.save()`, the developer of a project can determine how to sync 
this data.

Cheers.
Tai.


On Thursday, 5 April 2012 00:57:57 UTC+10, 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. 
>
> As the original author and designer of that pattern, I should probably 
> point out that I now think it's a mistake. Have you actually tried using 
> it? It doesn't really work very well. Every time I've introduced any sort 
> of "swappable model" mechanism I've come to regret it.
>
> I'm -1 on the idea of generalized

Re: [GSoC 2012] auth.User replacement proposal

2012-04-04 Thread Jacob Kaplan-Moss
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 requirement of GSoC that can sometimes bite us. I 
understand the intention -- they want to be sure students are the ones actually 
doing the work -- but it can be annoying for projects like this.

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.



Re: auth.user refactor: the profile aproach

2012-04-04 Thread bhuztez
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 different user model, LazyForeignKey can't be any
help. Maybe the only way to solve this is to add a schema migration
tool. When schema migration tool found a ForeignKey link to a
different model than before, it raises a error, then I know there is
something wrong.


On Apr 5, 8:45 am, Russell Keith-Magee 
wrote:
> 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 contains another example of exactly the same pattern
> >> -- Comments.
>
> >> As the original author and designer of that pattern, I should probably 
> >> point
> >> out that I now think it's a mistake. Have you actually tried using it? It
> >> doesn't really work very well. Every time I've introduced any sort of
> >> "swappable model" mechanism I've come to regret it.
>
> > Totally agree with Jacob here, plus Tai's comment that "There is such
> > a thing as too generic." We've made the mistake of making things too
> > generic in the past, and it's kind of infuriating in retrospect, both
> > philosophically and in terms of code maintenance/understanding.
> > (django/utils/tree.py, anyone??)
>
> > I think our policy should be: make the simplest thing that can
> > possibly work for a narrowly-tailored use case, then make things more
> > generic *slowly* if there's a demand. No need to be an Architecture
> > Astronaut.
>
> Certainly agreed that astronauting is a bad thing.
>
> However, I would like to draw attention to one particular benefit of the 
> generic solution (other than being generic):
>
> Once we make User swappable, every app with a model that has a ForeignKey to 
> User will need to be updated. This can be done slowly; existing projects that 
> use auth.User will continue to work. However there won't be any real alert to 
> the fact that the app requires updating until you try to swap out User and 
> things start to break. This breakage will be somewhat unpredictable -- you'll 
> just be observing side effect errors as a result of a non-existent (or empty) 
> auth_user table.
>
> Under the approach I described, User will be marked (in the Meta object) as 
> swappable, and ForeignKey(User) will be a hard link to a swapapble model, 
> which is something we can catch as a validation warning, providing a cue to 
> developers that there are apps in their project that may need to be updated. 
> And if there is a ForeignKey(User) and settings.USER_MODEL *isn't* User, then 
> we can raise an validation error, because we know that this app won't work.
>
> Even if we don't implement a fully generic solution, I think this property of 
> the generic approach is worth preserving.
>
> Yours,
> Russ Magee %-)

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

2012-04-04 Thread Stephen Burrows
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 project available as a third-party app?

--Stephen

On Apr 4, 5:41 pm, Alex Ogier  wrote:
> 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 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.