Re: auth.user refactor: the profile aproach

[Alex Ogier]

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

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

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

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

Respectfully,
Alex Ogier
On Apr 6, 2012 1:21 AM, "Donald Stufft"  wrote:

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

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

Re: [GSoC 2012] Schema Alteration API proposal

[j4nu5]

On Thursday, 5 April 2012 21:25:19 UTC+5:30, Andrew Godwin wrote:
>
> Just thought I'd chime in now I've had a chance to look over the current 
> proposal (I looked at the current one you have in the GSOC system):
>
>   - When you describe feeding things in from local_fields, are you 
> referring to that being the method by which you're planning to implement 
> things like syncdb?
>
Actually I am not planning to mess with syncdb and other management
commands. I will only refactor django.db.backends creation functions
like sql_create_model etc. to use the new API. Behaviour and functionality
will be the same after refactor, so management commands like syncdb
will not notice a difference.
 

>   - I'd like to see a bit more detail about how you plan to test the 
> code - specifically, there are some backend-specific tests you may need, 
> as well as some detailed introspection in order to make sure things have 
> applied correctly.
>
Currently, I can only think of things like the unique index on SQLite and
oddities in MySQL mostly again from South's test suite, I will give another
update before today's deadline.
 

> - Russ is correct about your models approach - as I've said before in 
> other places, the models API in Django is not designed with models as 
> moveable, dynamic objects.
>
I have taken care of clearing the app cache, after migrations.
Actually the entire point of using these 'Django code' based tests is that I
wanted to doubly ensure that Django will behave the way its supposed to
after the migrations. I could have gone with a SQL only approach e.g. 
'SELECT
table' after calling db.delete_table but using testing using Django code 
seemed
a bit more comprehensive.
Now, to mimic migrations, I needed to alter model definitions. The closest 
way
to resemble actual migration scenario seemed to be to change the definitions
in models.py itself. File rename/rewrite is ugly and OS dependent thats why 
I
used a 'temporary setting' based approach. I know that messing with app 
cache
looks a bit hackish but I cannot think of anything else for now.

South has one approach to these sorts of 
> tests, but I'd love to see a cleaner suggestion.
>
Are you referring to the fake orm? Well if you are satisfied with my above
explanation, there would be no need for it, since we will be using django's
orm.
 

> - There's been some discussion on south-users about the benefits of a 
> column-based alteration API versus a field/model-based alteration API - 
> why have you picked a column-based one? If you plan to continue using 
> Django fields as type information (as South does), what potential issues 
> do you see there?
>
Well you said it yourself above that "the models API in Django is not
designed with models as moveable, dynamic objects". That is why I used
a column-based approach. The advantage will be felt in live migrations.
As for using Django fields for type information, I frankly cannot think of a
major valid negative point for now, I will revert later today.
 

> - Some more detail on your background would be nice - what's your 
> specific experience with the 3 main databases you'll be handling 
> (postgres, mysql, sqlite)? What was a "high voltage database migration"?
>
Sure. I will update it.
 

> Sorry for the late feedback, I've been far too busy.
>
No problem, as long as you reply to this before the deadline :D

>

-- 
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/-/5eBCoe2syNYJ.
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

[Donald Stufft]

Nothing about this proposal prevents this.

And in that case, no those 2 apps would not be able to be used together. But 
this is hardly the first 
time that 2 apps cannot be used together. because of choices made like that on 
the app owner.


On Friday, April 6, 2012 at 1:18 AM, Harris Lapiroff wrote:

> I very much share Tai's concerns about the swappable user model introducing 
> incompatibilities. Imagine two apps, each of which requires an "age" 
> attribute on the user model. But suppose one of those apps expects age to be 
> the number of years since that user's birth and one of those apps expects the 
> age to be the number of years since the user registered for the website. The 
> user model must provide the same attribute to both apps, but it is supposed 
> to have a different value for each app. A developer will be unable to use 
> these two apps together without patching one of them.
> 
> A bit of a contrived example, maybe, but I can imagine this 
> same-name-different-purpose issue coming up over and over again, making 
> otherwise pluggable apps incompatible with each other.
> 
> I think we should go with a pared down user model and allow each app to 
> manage whatever data it needs on each user through profiles and signals. 
> Developers will end up with some data duplication, but I think that is 
> preferable to confusion about the source and purpose of data. Profiles are 
> essentially a way for each app to namespace its own data and I think that's a 
> good thing.
> 
> Harris
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-developers/-/p4jhylEp3x8J.
> To post to this group, send email to django-developers@googlegroups.com 
> (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: auth.user refactor: the profile aproach

[Harris Lapiroff]

I very much share Tai's concerns about the swappable user model introducing 
incompatibilities. Imagine two apps, each of which requires an "age" 
attribute on the user model. But suppose one of those apps expects age to 
be the number of years since that user's birth and one of those apps 
expects the age to be the number of years since the user registered for the 
website. The user model must provide the same attribute to both apps, but 
it is supposed to have a different value for each app. A developer will be 
unable to use these two apps together without patching one of them.

A bit of a contrived example, maybe, but I can imagine this 
same-name-different-purpose issue coming up over and over again, making 
otherwise pluggable apps incompatible with each other.

I think we should go with a pared down user model and allow each app to 
manage whatever data it needs on each user through profiles and signals. 
Developers will end up with some data duplication, but I think that is 
preferable to confusion about the source and purpose of data. Profiles are 
essentially a way for each app to namespace its own data and I think that's 
a good thing.

Harris

>

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

Re: auth.user refactor: the profile aproach

[bhuztez]

I think we need three different kinds of models, Identity, Profile and
Authentication Info.

 * The Identity model should have all fields shared by many apps.
 * Each app can have its own Profile model. If a field is not shared
with other apps, just put it in the Profile model.
 * Since password is never used after an user is authenticated,
authentication backends should declare fields like passwords, OpenID
credentials in their own Authentication Info models.

Having any default fields in the Identity model is not appropriate,
most likely we will find a use case in which a certain field is not
needed. But if the Identity model has only PK field, data
synchronization will be a big problem, for each field shared by
multiple apps, you need a signal, and suppose you have 20 models and
they have 3 fields in common, when you changed these 3 fields in one
object, you will have another 19 objects saved three times each.

Furthurmore, a project may need more than one Identity model. Both
LazyForeignKey and multiple Profile solution do not address this
problem. Since any app may have its own APP_IDENTITY_MODEL setting,
the unpredictable problem if APP_IDENTITY_MODEL changed after initial
syncdb, is unavoidable. IMO, this problem can only be solved schema
migration tool and should be solved by schema migration tool. If
Django ORM assumes that schema would be changed overtime, schema
migration should not be an optional part of it.




On Apr 6, 9:52 am, Tai Lee  wrote:
> Thanks Anssi, but I think the interface contract for a pluggable app *should* 
> be on the pluggable app's profile, instead of relying on an assumption that 
> developers will have created a user model that is duck typed to suit every 
> pluggable app installed in the project (which might not be practical or even 
> possible).
>
> For the sake of avoiding duplication, which could be managed with signals and 
> the save() method of a project level profile, you potentially overload fields 
> that are not analogous across pluggable apps by sharing a single namespace. 
> E.g. is_active for the admin may not mean is_active for app2 or app3.
>
> Jacob, by having to define a minimum set of fields that users must implement 
> in their swappable User model to support contrib apps like the admin, don't 
> we end up exactly where we are now? Isn't this exactly what we have already?
>
> The only difference I see then is that the interface would be defined in docs 
> instead of a model and re-implemented by developers for every project, and 
> pluggable apps will often require a schema migration on the swapped-in 
> project level User model when adding a pluggable app to an established 
> project.
>
> In my ideal scenario, User would be a glue model with just a PK, and maybe 
> some convenience methods. AdminProfile would not have username or password 
> fields, but would have is_active, is_superuser, and maybe optionally a name, 
> etc.
>
> Developers would need to create at least one model in their project, which 
> would be a subclass of BaseAuthModel in most cases, which stores 
> authentication credentials.
>
> They would also need to create an auth backend, which would be a subclass of 
> BaseAuthBackend in most cases.
>
> Pluggable apps could also define auth models and backends if they require 
> specific auth to function (e.g. an app that adds twitter integration.)
>
> Then people could login to the admin and any other pluggable apps using 
> whatever credentials and authentication system they like (username/email and 
> password, twitter, Facebook, openid, etc.) Developers wouldn't need to 
> implement a minimal set of fields or do a database schema migration to 
> support or install any pluggable apps.
>
> If app1 or app2 require access to an email address (for example), their 
> profiles should have a required email field. It should be up to the project 
> developer to make sure that an email address is set when creating an app1 or 
> app2 profile for a User, and synchronizing them between app1 and app2 (if 
> appropriate).
>
> I think the data duplication issue is much easier for project developers to 
> manage explicitly without resorting to magic and assumptions than sharing or 
> combining namespaces for profile data, doing database scheme migrations, and 
> duck typing a single model for use with multiple pluggable apps.
>
> Cheers.
> Tai.
>
> On 06/04/2012, at 7:42 AM, Anssi Kääriäinen  wrote:
>
>
>
>
>
>
>
> > On Apr 5, 11:29 pm, Tai Lee  wrote:
> >> But I still don't see how a swapped in `User` model which *has* to behave 
> >> in a specified way so that it can work with the Django admin and any other 
> >> pluggable apps that might have special requirements, is any better than 
> >> simply allowing the admin and other pluggable apps to have their profile 
> >> and authentication needs self-contained?
>
> >> If Django's `User` model was just a stub (without even 

Re: auth.user refactor: the profile aproach

[Tai Lee]

Thanks Anssi, but I think the interface contract for a pluggable app *should* 
be on the pluggable app's profile, instead of relying on an assumption that 
developers will have created a user model that is duck typed to suit every 
pluggable app installed in the project (which might not be practical or even 
possible). 

For the sake of avoiding duplication, which could be managed with signals and 
the save() method of a project level profile, you potentially overload fields 
that are not analogous across pluggable apps by sharing a single namespace. 
E.g. is_active for the admin may not mean is_active for app2 or app3.

Jacob, by having to define a minimum set of fields that users must implement in 
their swappable User model to support contrib apps like the admin, don't we end 
up exactly where we are now? Isn't this exactly what we have already?

The only difference I see then is that the interface would be defined in docs 
instead of a model and re-implemented by developers for every project, and 
pluggable apps will often require a schema migration on the swapped-in project 
level User model when adding a pluggable app to an established project.

In my ideal scenario, User would be a glue model with just a PK, and maybe some 
convenience methods. AdminProfile would not have username or password fields, 
but would have is_active, is_superuser, and maybe optionally a name, etc.

Developers would need to create at least one model in their project, which 
would be a subclass of BaseAuthModel in most cases, which stores authentication 
credentials.

They would also need to create an auth backend, which would be a subclass of 
BaseAuthBackend in most cases.

Pluggable apps could also define auth models and backends if they require 
specific auth to function (e.g. an app that adds twitter integration.)

Then people could login to the admin and any other pluggable apps using 
whatever credentials and authentication system they like (username/email and 
password, twitter, Facebook, openid, etc.) Developers wouldn't need to 
implement a minimal set of fields or do a database schema migration to support 
or install any pluggable apps.

If app1 or app2 require access to an email address (for example), their 
profiles should have a required email field. It should be up to the project 
developer to make sure that an email address is set when creating an app1 or 
app2 profile for a User, and synchronizing them between app1 and app2 (if 
appropriate).

I think the data duplication issue is much easier for project developers to 
manage explicitly without resorting to magic and assumptions than sharing or 
combining namespaces for profile data, doing database scheme migrations, and 
duck typing a single model for use with multiple pluggable apps.

Cheers.
Tai.


On 06/04/2012, at 7:42 AM, Anssi Kääriäinen  wrote:

> On Apr 5, 11:29 pm, Tai Lee  wrote:
>> But I still don't see how a swapped in `User` model which *has* to behave in 
>> a specified way so that it can work with the Django admin and any other 
>> pluggable apps that might have special requirements, is any better than 
>> simply allowing the admin and other pluggable apps to have their profile and 
>> authentication needs self-contained?
>> 
>> If Django's `User` model was just a stub (without even username and password 
>> fields), and Django shipped with an abstract `BaseAuth` model with a 
>> `username` field that was email compliant and a `password` field, and 
>> corresponding `BaseAuthForm` and `BaseAuthBackend`, then user's can still 
>> create their own `User` model with literally *whatever* fields they want in 
>> it, they can use the standard auth fields, form and backend provided by 
>> Django, or roll their own.
>> 
>> Instead of creating a custom `User` model that quacks like an admin duck, 
>> and quacks like every pluggable app that is installed as well, all they need 
>> to do is create/update an an `AdminUser` whenever their custom `User` is 
>> saved.
>> 
>> This is explicit, the admin and other pluggable apps know where to access 
>> information that they need (from their own models), and the developer has 
>> control over how the data is kept in sync across the pluggable apps used in 
>> the project, at the project level.
> 
> If every application provides a profile which matches it needs, you
> will get a serious case of data-duplication. Every application which
> needs email-address should then create a profile containing the email.
> Another way to solve this would be to check the existing profiles for
> the email field, and now you have introduced some magic, and in
> addition you have mostly just moved the interface contract from the
> User model to its profile. So, you have the same problem again. This
> is the failing of the profile based approach: you don't actually solve
> anything by it, you just move the problem around (and introduce more
> problems by doing that). (Yes, I was 

Re: auth.user refactor: the profile aproach

[Russell Keith-Magee]

On 06/04/2012, at 7:27 AM, Jacob Kaplan-Moss wrote:

> On Thursday, April 5, 2012 at 12:04 PM, Alex Gaynor wrote:
>> I haven't been following this thread nearly closely enough.  But ISTM that 
>> any abstraction that doesn't let the admin work with any User (assuming it 
>> supplies the right interface) isn't very useful, and rather misses the point.
>> 
> 
> I'm starting to come to the conclusion that as part of this process we'll 
> need to document a sort of "minimal viable user" -- the smallest set of user 
> APIs that a reusable app -- including the admin -- can reasonably rely on. If 
> we're fairly clear about this interface then it remains fairly easy to 
> produce apps that rely on auth in an abstract way. In fact, this sort of 
> "minimal user" might even make auth-dependant reusable apps *more* prevalent 
> since at the moment the set of user APIs are rather nebulous and 
> ill-specified. 

It's a good thing that I didn't document that as a "universal concern" on the 
wiki right from the start ...

https://code.djangoproject.com/wiki/ContribAuthImprovements#TheUserContract

Oh wait...

:-)

Russ %-)

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

[Jacob Kaplan-Moss]

On Thursday, April 5, 2012 at 12:04 PM, Alex Gaynor wrote:
> I haven't been following this thread nearly closely enough.  But ISTM that 
> any abstraction that doesn't let the admin work with any User (assuming it 
> supplies the right interface) isn't very useful, and rather misses the point.
> 

I'm starting to come to the conclusion that as part of this process we'll need 
to document a sort of "minimal viable user" -- the smallest set of user APIs 
that a reusable app -- including the admin -- can reasonably rely on. If we're 
fairly clear about this interface then it remains fairly easy to produce apps 
that rely on auth in an abstract way. In fact, this sort of "minimal user" 
might even make auth-dependant reusable apps *more* prevalent since at the 
moment the set of user APIs are rather nebulous and ill-specified. 

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

[Anssi Kääriäinen]

On Apr 5, 11:29 pm, Tai Lee  wrote:
> But I still don't see how a swapped in `User` model which *has* to behave in 
> a specified way so that it can work with the Django admin and any other 
> pluggable apps that might have special requirements, is any better than 
> simply allowing the admin and other pluggable apps to have their profile and 
> authentication needs self-contained?
>
> If Django's `User` model was just a stub (without even username and password 
> fields), and Django shipped with an abstract `BaseAuth` model with a 
> `username` field that was email compliant and a `password` field, and 
> corresponding `BaseAuthForm` and `BaseAuthBackend`, then user's can still 
> create their own `User` model with literally *whatever* fields they want in 
> it, they can use the standard auth fields, form and backend provided by 
> Django, or roll their own.
>
> Instead of creating a custom `User` model that quacks like an admin duck, and 
> quacks like every pluggable app that is installed as well, all they need to 
> do is create/update an an `AdminUser` whenever their custom `User` is saved.
>
> This is explicit, the admin and other pluggable apps know where to access 
> information that they need (from their own models), and the developer has 
> control over how the data is kept in sync across the pluggable apps used in 
> the project, at the project level.

If every application provides a profile which matches it needs, you
will get a serious case of data-duplication. Every application which
needs email-address should then create a profile containing the email.
Another way to solve this would be to check the existing profiles for
the email field, and now you have introduced some magic, and in
addition you have mostly just moved the interface contract from the
User model to its profile. So, you have the same problem again. This
is the failing of the profile based approach: you don't actually solve
anything by it, you just move the problem around (and introduce more
problems by doing that). (Yes, I was +1 on the idea. Opinions
change...)

I guess 90% of users will either use the BackwardsCompatibilityUser,
or the new shiny FixedUser. For most users they are more than
adequate. The issue is only when you really need something completely
different for one reason or another. In addition with proxy models and
custom managers you can have pretty good profile based approach in the
cases where you need it. It is a good approach if you have
TwitterUser, FaceBookUser, GooglePlusUser and so on. (Or CustomerUser,
EmployeeUser and so on).

I bet one of the hardest problems will be how to define the ORM
interface, and how custom classes can fulfill
that. .filter(is_admin=True) can only work if there is a is_admin
field. I guess everything will need to go through manager methods, and
the "must implement" set must be kept at minimum.

 - Anssi

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

Re: Allow changing form field properties after form creation

[Simon Meers]

On 6 April 2012 07:26, Beres Botond  wrote:
> Hi Chris,
>
> Isn't it this what you are trying to do?
>
> class DocumentForm(ModelForm):
>        def __init__(self, *args, **kwargs):
>                super(MyForm, self).__init__(*args, **kwargs)
>                self.fields['title'].required = False
>
> Which works perfectly fine. You can tweak pretty much any property at
> runtime like that, without replacing the field entirely.

This discussion is sounding more like something that belongs in
django-users. I agree that there are some improvements that can be
made to make field-tweaking easier and more elegant, as proposed in
[1] which Keryn pointed out in [2]. It would probably be better to
continue this conversation in those tickets.

Simon

[1] https://code.djangoproject.com/ticket/17924
[2] https://code.djangoproject.com/ticket/18064

-- 
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: Allow changing form field properties after form creation

[Beres Botond]

Hi Chris,

Isn't it this what you are trying to do?

class DocumentForm(ModelForm):
def __init__(self, *args, **kwargs):
super(MyForm, self).__init__(*args, **kwargs)
self.fields['title'].required = False

Which works perfectly fine. You can tweak pretty much any property at
runtime like that, without replacing the field entirely.


Regards,

Boti

On Apr 5, 5:03 pm, Chris Wilson  wrote:
> Hi Brian,
>
> On Thu, 5 Apr 2012, Brian Neal wrote:
> > On Thursday, April 5, 2012 6:49:20 AM UTC-5, Chris Wilson wrote:
>
> >       class DocumentForm(ModelForm):
> >            title =
> >       models.Document._meta.get_field('title').formfield(required=False)
>
> > You can already replace and tweak the fields in a way similar to what you 
> > are proposing. For example, you can create a Form or ModelForm, and in the 
> > __init__() you can do:
>
> > def __init__(self, *args, **kwargs):
> >     super(MyForm, self).__init__(*args, **kwargs)
> >     self.fields['title'] = models.Charfield(max_length=30, required=False)
>
> Thanks, yes, I can replace the entire field but I can't tweak its
> properties. I.e. I can do exactly what I was doing before, in __init__,
> like this:
>
> class DocumentForm(ModelForm):
>         def __init__(self, *args, **kwargs):
>                 super(MyForm, self).__init__(*args, **kwargs)
>                 self.fields['title'] =
> models.Document._meta.get_field('title').formfield(required=False)
>
> But that's even longer. I'm trying to propose a simple way to tweak
> certain properties of a field after it's created, without replacing the
> field, in a way that meets my requirements as described in the previous
> email and that's pythonic and simple and likely to be accepted by Django.
>
> Cheers, Chris.
> --
> Aptivate |http://www.aptivate.org| Phone: +44 1223 967 838
> Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
>
> Aptivate is a not-for-profit company registered in England and Wales
> with company number 04980791.

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

[Tai Lee]

On 06/04/2012, at 3:09 AM, Ian Lewis wrote:

> The good part about swappable user models is that you don't need to 
> necessarily fix the model's DB fields in advance. Your identifier and 
> password's length and other properties can be user defined and can be 
> reflected in the DB.
> 
> Django can also leave migration of user models an data up to the developer so 
> they an use south or whatever to manage the user model since they "own" it. 
> Django Devs wouldn't necessarily need to support a DB table that can 
> essentially never change as is the case currently.
> 
> Fixing that stuff ahead of time and just making a FK means the user model 
> itself is fixed. I don't want to be able to just add fields. I want to be 
> able to change the primary key to be a uuid, or a email, or use the default 
> auto incrementing integer. I want to be able to use an existing model or DB 
> table and, with some work, plug it into Django auth.
> 
> Now if I'm customizing the user model itself anyway, why not just tack on 
> whatever other fields I want? I don't need a FK since those fields are on the 
> user model and I can create however many one to one or one to many 
> relationships for "profiles" or user data as makes sense for my project. That 
> may be a lot or it may be zero. 
> 
> (now whether that is realistic given the needs of the admin is a different 
> story)

But I still don't see how a swapped in `User` model which *has* to behave in a 
specified way so that it can work with the Django admin and any other pluggable 
apps that might have special requirements, is any better than simply allowing 
the admin and other pluggable apps to have their profile and authentication 
needs self-contained?

If Django's `User` model was just a stub (without even username and password 
fields), and Django shipped with an abstract `BaseAuth` model with a `username` 
field that was email compliant and a `password` field, and corresponding 
`BaseAuthForm` and `BaseAuthBackend`, then user's can still create their own 
`User` model with literally *whatever* fields they want in it, they can use the 
standard auth fields, form and backend provided by Django, or roll their own.

Instead of creating a custom `User` model that quacks like an admin duck, and 
quacks like every pluggable app that is installed as well, all they need to do 
is create/update an an `AdminUser` whenever their custom `User` is saved.

This is explicit, the admin and other pluggable apps know where to access 
information that they need (from their own models), and the developer has 
control over how the data is kept in sync across the pluggable apps used in the 
project, at the project level.

Cheers.
Tai.

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

Re: django.contrib.sites.managers.CurrentSiteManager spanning more than one model

[Rory Geoghegan]

The only hard part is modifying the _validate_field_name method.
get_query_set uses the regular filtering mechanism, so it actually works
out of the box with the __ field spanning. I will provided a patch (once I
clean up the code), then you can see that it is quite a small fix and may
be worth integrating.

--Rory Geoghegan

On Thu, Apr 5, 2012 at 3:46 PM, Adrian Holovaty  wrote:

> On Thu, Apr 5, 2012 at 11:46 AM, Rory Geoghegan
>  wrote:
> > We currently have that code written. Is it worth turning that into a
> > patch for contrib.sites, with unit tests et al, and pushing upstream
> > into django? Should I fill out a bug?
>
> I don't think this added complexity/functionality is worth adding to
> the framework. It's easy enough to make your own custom manager that
> does the same thing. If you'd like to share it with others, toss it
> online somewhere.
>
> 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: django.contrib.sites.managers.CurrentSiteManager spanning more than one model

[Adrian Holovaty]

On Thu, Apr 5, 2012 at 11:46 AM, Rory Geoghegan
 wrote:
> We currently have that code written. Is it worth turning that into a
> patch for contrib.sites, with unit tests et al, and pushing upstream
> into django? Should I fill out a bug?

I don't think this added complexity/functionality is worth adding to
the framework. It's easy enough to make your own custom manager that
does the same thing. If you'd like to share it with others, toss it
online somewhere.

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

[Łukasz Rekucki]

On 5 April 2012 19:45, Alex Ogier  wrote:
>
>> >> class User(models.Model):
>> >>     MALE = 0
>> >>     FEMALE = 1
>> >>     GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')]
>> >>     gender = models.IntegerField(choices=GENDERS)
>> >>
>> >>     def greet(self):
>> >>         return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender]
>> >>
>>
>> I' sure you meant:
>>
>> def greet(self):
>>    return {self.MALE: 'Hi, boy', self.FEMALE: 'Hi, girl.'}[self.gender]
>>
>> Unless you defined MALE/FEMALE as globals too :) Otherwise you'll get
>> a NameError.
>>
>> --
>> Łukasz Rekucki
>
> As attributes of the class object I'm pretty sure they are in scope. No
> NameErrors there.
>

That's not how it works. Code that executes when creating a new class
does not define a lexical scope. There is no such thing as "class
scope". Try it yourself:

http://ideone.com/xbr0q

-- 
Łukasz Rekucki

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

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

[Alex Ogier]

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

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

Best,
Alex Ogier

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

django.contrib.sites.managers.CurrentSiteManager spanning more than one model

[Rory Geoghegan]

Hi,

The current implementation of CurrentSiteManager only 'spans' one
model. For example, take the following code:

class Foo(models.Model):
[...]
site = models.OneToOneField('sites.Site')
on_site = CurrentSiteManager("site")

class Bar(models.Model):
[...]
foo = models.ManyToManyField(Foo)

What I would really want is to do the following:

class Bar(models.Model):
[...]
foo = models.ManyToManyField(Foo)
on_site = CurrentSiteManager("foo__site")

, and have it "just work" by jumping through the 'foo' field onto the
'site' field on the Foo model.

We currently have that code written. Is it worth turning that into a
patch for contrib.sites, with unit tests et al, and pushing upstream
into django? Should I fill out a bug?

Thanks in advance,
--Rory Geoghegan

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

[Ian Lewis]

Hi

iPhoneから送信

On 2012/04/06, at 0:29, "Daniel Sokolowski"  
wrote:
> The more I think about it the more it makes sense to me to have a base User 
> model just a stub with a user Identifier and password field. Sure one could 
> argue for less ore more fields, but I think the idea
> is to pick something that would work in 95% situations and yet be flexible 
> enough to be extended as you wish. Need to extend to add your own 
> authorization you create a profile with a FK key to the base model and
> a new auth backend.

The good part about swappable user models is that you don't need to necessarily 
fix the model's DB fields in advance. Your identifier and password's length and 
other properties can be user defined and can be reflected in the DB.

Django can also leave migration of user models an data up to the developer so 
they an use south or whatever to manage the user model since they "own" it. 
Django Devs wouldn't necessarily need to support a DB table that can 
essentially never change as is the case currently.

Fixing that stuff ahead of time and just making a FK means the user model 
itself is fixed. I don't want to be able to just add fields. I want to be able 
to change the primary key to be a uuid, or a email, or use the default auto 
incrementing integer. I want to be able to use an existing model or DB table 
and, with some work, plug it into Django auth.

Now if I'm customizing the user model itself anyway, why not just tack on 
whatever other fields I want? I don't need a FK since those fields are on the 
user model and I can create however many one to one or one to many 
relationships for "profiles" or user data as makes sense for my project. That 
may be a lot or it may be zero. 

(now whether that is realistic given the needs of the admin is a different 
story)


> Perhaps the reason the current contib.auth is still not overhauled is because 
> it does work for a large number of situation and extending it is relatively 
> easy. Keep the solution simple - I think we are overthinking it.

Sure. I'm not completely discontent continuing to use my own library and simply 
shun anything that uses auth (besides the admin maybe), but I think Django 
would be better off with a better auth module. 


> -Original Message- From: Russell Keith-Magee
> Sent: Wednesday, April 04, 2012 10:44 AM
> To: django-developers@googlegroups.com
> Subject: 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. 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.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

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

Re: auth.user refactor: the profile aproach

[Alex Gaynor]

On Thu, Apr 5, 2012 at 1:02 PM, Adrian Holovaty  wrote:

> 2012/4/5 Ian Lewis :
> > I'm curious though how the admin fits into your ideas. If you wanted to
> use the
> > admin, would you have to use a User model that has and or supports all
> the
> > cruft on the current user model? e.g. username, password, email,
> permissions
> > etc.
>
> Yes, you'd need to tell the admin how your User model interacted with
> it -- how it authenticates, how permissions work, etc.
>
> 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.
>
>
I haven't been following this thread nearly closely enough.  But ISTM that
any abstraction that doesn't let the admin work with any User (assuming it
supplies the right interface) isn't very useful, and rather misses the
point.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

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

Re: auth.user refactor: the profile aproach

[Adrian Holovaty]

2012/4/5 Ian Lewis :
> I'm curious though how the admin fits into your ideas. If you wanted to use 
> the
> admin, would you have to use a User model that has and or supports all the
> cruft on the current user model? e.g. username, password, email, permissions
> etc.

Yes, you'd need to tell the admin how your User model interacted with
it -- how it authenticates, how permissions work, etc.

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

[Ian Lewis]

Hi. 

iPhoneから送信

On 2012/04/04, at 5:34, Adrian Holovaty  wrote:
> First, some background: I haven't used the built-in User module in
> several years. I always write my own User model from scratch -- it's
> so nice and clean. Want a twitter_username field? Just add it. No need
> to add a convoluted foreign key or (oh god) one-to-one relationship to
> some other table.
> 
> To me, this is the Right Way to do things. The framework should bend
> to my needs, I shouldn't bend to the framework's needs.
> 
> Also, profile modules need to die. They needed to die circa 2006.

Yes, Yes, Yes. I'm really glad someone besides me disliked user profiles and 
favored just creating your own user model. I was feeling lonely.

Just like Adrian, me and everyone at my company have used our own user models 
for years. It always felt like the simplest and most straight-forward approach. 
It also has the be benefit that users can use south or anything they want. For 
migrating and managing user data. Big big +1.

> So, with that in mind, I've got to say I prefer Alex's solution. I
> really think the right way to do it is:
> 
> 1. Let you create your own User model, with whichever fields you want.
> 
> 2. Provide a way to tell Django which model you're using for that.
> 
> 3. In your own code, just deal with that model like you deal with any
> other one. No need to jump through hoops.
> 
> 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 wanted to point out that Adrien's plan is pretty close to newauth. Though I 
didn't go so far as to provide a UserField, I did have a way for third party 
apps to get a handle of the User model via a get_user_model() function. The 
UserField would just glue something like that to a ForeignKey.

> 6. Given that some third-party apps will likely want to get access to
> common attributes of a User -- notably, email address -- there could
> be some sort of standard interface that User models need to adhere to
> (duck typing). So, a custom User model would say "for this User model,
> the email address is stored in the database field called 'email'" --
> or "this User model doesn't have email addresses.

I think people get too hung up on providing fields do third party apps when you 
could provide a minimal set of methods which subclasses could override. There 
isn't really any reason i can think of that third party apps need to access the 
fields directly.

Though if you really hav to deal with fields, I prefer a simple convention for 
common fields; for example, 'email' for the email field. That way you can do a 
simple hasattr() to look if the model has a particular field. I realize 
convention is hard to document though.

I'm curious though how the admin fits into your ideas. If you wanted to use the 
admin, would you have to use a User model that has and or supports all the 
cruft on the current user model? e.g. username, password, email, permissions 
etc.

All in all I'm excited about where this is going and that you're taking the 
lead on this. Can't thank you enough. 

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

[Daniel Sokolowski]

No I can not stomach a swappable User model or the LFK approach, so thank you 
for voicing your concerns.

From: Tai Lee 
Sent: Wednesday, April 04, 2012 9:37 PM
To: django-developers@googlegroups.com 
Subject: 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 `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 

Re: [GSoC 2012] Schema Alteration API proposal

[Andrew Godwin]

Just thought I'd chime in now I've had a chance to look over the current 
proposal (I looked at the current one you have in the GSOC system):


 - When you describe feeding things in from local_fields, are you 
referring to that being the method by which you're planning to implement 
things like syncdb?


 - I'd like to see a bit more detail about how you plan to test the 
code - specifically, there are some backend-specific tests you may need, 
as well as some detailed introspection in order to make sure things have 
applied correctly.


- Russ is correct about your models approach - as I've said before in 
other places, the models API in Django is not designed with models as 
moveable, dynamic objects. South has one approach to these sorts of 
tests, but I'd love to see a cleaner suggestion.


- There's been some discussion on south-users about the benefits of a 
column-based alteration API versus a field/model-based alteration API - 
why have you picked a column-based one? If you plan to continue using 
Django fields as type information (as South does), what potential issues 
do you see there?


- Some more detail on your background would be nice - what's your 
specific experience with the 3 main databases you'll be handling 
(postgres, mysql, sqlite)? What was a "high voltage database migration"?


Sorry for the late feedback, I've been far too busy.

Andrew

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

[Daniel Sokolowski]

Can someone give me an example please where a swappable model would benefit 
me as opposed to one-to-one model inheritance, FKs, or even proxy models? 
Django does this very well and allows

for seamless up/down traversal.

It seems that swappable models are nothing but a different way of doing what 
I already am doing for when I am extending the flat pages; except that it 
ads a nice centralized SWAPPABLE_MODELS setting.
Furthermore if I do make a swappable custom user model the correct 
implementation of 'standard' User methods depends on me; sure I could extend 
a the base User model and inherit these methods but then

what did I gained by having this swappable model concept?

The more I think about it the more it makes sense to me to have a base User 
model just a stub with a user Identifier and password field. Sure one could 
argue for less ore more fields, but I think the idea
is to pick something that would work in 95% situations and yet be flexible 
enough to be extended as you wish. Need to extend to add your own 
authorization you create a profile with a FK key to the base model and

a new auth backend.

Perhaps the reason the current contib.auth is still not overhauled is 
because it does work for a large number of situation and extending it is 
relatively easy. Keep the solution simple - I think we are overthinking it.




-Original Message- 
From: Russell Keith-Magee

Sent: Wednesday, April 04, 2012 10:44 AM
To: django-developers@googlegroups.com
Subject: 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. 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.


--
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: GSOC2012 Proposal for 'Finishing off the App Refactor'

[Nauho Zen]

Enhanced proposal:


*Proposal For “Finishing off the App Refactor”*

* *

* *

*Abstract*

---

Django currently assumes that an application will only ever be loaded once,
and that the name of that application will be determined solely by the
package name holding the models.py. A gread idea has been proposed as a
GSOC idea in 2010[1] and continued in 2011[2], which will improve the old
app loading mechism a lot, e.g. deploy several instances of the same
application, deploy two applications with the same name, supportconvenient
interface for internationalizing application names, etc. However, the
[2]branch is not well prepared for being merged to the master branch, and
work been made in 2010 and 2011 towards these feathers has made some big
changes to current codebase, see[3]. So it's very necessary to check the
changes and make sure whether these work can be merged and everything runs
smoothly or not after merged.





*Introduction*

-

Because the purpose is to check if everything runs ok after merged, so we
should know what kind of features current app loading mechanism supports
and what kind of improvements 'future' advanced work has made.



1 current app loading features

1> reused app can be found by Django in INSTALLED_APPS of settings.py,
which is written in dotted path

2> each string in INSTALLED_APPS should be a full Python path to a Python
package that contains a Django application, as created by django-admin.py
startapp

3> app names must be unique



2 'future' app loading features

1> backward compatibility: 'future' app loading mechanism should support
current app loading features well

2> can deploy several instaces of the same application

3> can deploy two applications with the same name,(not have the
requirements of unique app name)

4> convenient interface for internationalizing application names

5> good support to rename an application with a name that isn't helpful
from a UI perspective



While,how to check these above, I think the best tool we can use is
unit-test. First, we should check if all the funtions(get_apps,
get_app,get_models, etc.) still work after these changes, thus the test
cases towards these funtions should be run again to see if all is ok.
Second, good use cases should be establised to check if it still supports
current features well; we can borrow these use cases from previous work I
think. Third, also construct good use cases be used to check if
will-be-added features work well after merged, we can reuse the tests new
app-loading has offered.



But to the unittest point of view, we should pay more attention on the
files which has been modified. Specifically, except for the unittest files,
in [3], 6 files are added, 20 files are modifiled. Thus one part important
work is to check if file changes does make bad or unexpected  consequenses
or not. Towards unittest files, 21 files are added, 1 file is removed, 6
files are modified, thus we also should check after these changes, whether
tests still cover old app loading unit test or not, what's more, cover new
features has been implemented in 2010 and 2011 well or not.



The best place to start is the pull request:
https://github.com/django/django/pull/129

This branch should do the following things in three aspects:

a) Introduce the concept of an App object to represent each

b) Keep the concept of an `app_label` as just the last part of an app's
module name (example: django.contrib.auth has an app_label of auth).

c) Be entirely backwards compatible



The majority of the above work is already done. Two biggest hurdles should
be considered to get the code merged in are:



a) Getting the main test suite running again.  The tests break
spectacularly with the new code.  Some of the failures are tests using
internal APIs that changed, other are valid public APIs that haven't been
ported yet.  Ideally this merge should be able to take place without a
single test having to be changed.

b) Buy-in from all of the core-devs that this is a needed and/or good
change.



According to the above considerations, the detailed plan is as follows:



*Detailed Plan:*



*Week 1*: Try to merge and check if old test cases can all be run
successfully, and make some necessary improvement work

*Week 2-3*: Establish good use cases to check if old app loading features
are all not been destroyed, meanwhile do necessary modification work

*Week 4*: Check all new test cases can be run sucessfully or not, and make
some necessary work to help pass all tests

*Week 5-6*: Construct use cases to check how many new features have already
been implemented, and if there are some interesting features that should be
added, then I can do necessary coding work

*Week 7*: Check if App object perform well or not and do necessary
improvement work

*Week 8*: Check if the concept of ‘app_label’ perform well not (vs.
‘app_name’) and do necessary improvement work

*Week 9*: Make sure if the branch is 

Re: Allow changing form field properties after form creation

[Chris Wilson]

Hi Brian,

On Thu, 5 Apr 2012, Brian Neal wrote:


On Thursday, April 5, 2012 6:49:20 AM UTC-5, Chris Wilson wrote:

  class DocumentForm(ModelForm):
       title =
  models.Document._meta.get_field('title').formfield(required=False)

You can already replace and tweak the fields in a way similar to what you are 
proposing. For example, you can create a Form or ModelForm, and in the 
__init__() you can do:

def __init__(self, *args, **kwargs):
    super(MyForm, self).__init__(*args, **kwargs)
    self.fields['title'] = models.Charfield(max_length=30, required=False)


Thanks, yes, I can replace the entire field but I can't tweak its 
properties. I.e. I can do exactly what I was doing before, in __init__, 
like this:


class DocumentForm(ModelForm):
def __init__(self, *args, **kwargs):
super(MyForm, self).__init__(*args, **kwargs)
		self.fields['title'] = 
models.Document._meta.get_field('title').formfield(required=False)


But that's even longer. I'm trying to propose a simple way to tweak 
certain properties of a field after it's created, without replacing the 
field, in a way that meets my requirements as described in the previous 
email and that's pythonic and simple and likely to be accepted by Django.


Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

--
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: Allow changing form field properties after form creation

[Brian Neal]

On Thursday, April 5, 2012 6:49:20 AM UTC-5, Chris Wilson wrote:
>
> Hi all,
>
> I've added this as a ticket but I wanted to make sure that the core 
> and forms developers have a chance to see and interact with it, so I'm 
> posting it here too. You can find the ticket at: 
> 
>
> Currently, if I want to tweak the properties of some fields in a 
> ModelForm, I have to replace them in the subclass like this:
>
> {{{
> class DocumentForm(ModelForm):
>  title = 
> models.Document._meta.get_field('title').formfield(required=False)
>  programs = 
> models.Document._meta.get_field('programs').formfield(required=False)
>  authors = 
> models.Document._meta.get_field('authors').formfield(required=False)
>  confidential = 
>
> models.Document._meta.get_field('confidential').formfield(widget=AdminYesNoWidget)
>  uploader = 
> models.Document._meta.get_field('uploader').formfield(required=False)
>  file = 
>
> models.Document._meta.get_field('file').formfield(widget=AdminFileWidgetWithSize)
> }}}
>
You can already replace and tweak the fields in a way similar to what you 
are proposing. For example, you can create a Form or ModelForm, and in the 
__init__() you can do:

def __init__(self, *args, **kwargs):
super(MyForm, self).__init__(*args, **kwargs)
self.fields['title'] = models.Charfield(max_length=30, required=False)
 

-- 
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/-/uyoFUewQrmIJ.
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: Allow changing form field properties after form creation

[Chris Wilson]

Hi Nate,

On Thu, 5 Apr 2012, Nate Bragg wrote:


They don't "have" to be replaced in a subclass in the way you showed.
Perhaps it isn't perfectly DRY, but whats so bad about naming the field
explicitly?


The fact that we're building reusable components and we want people to be 
able to subclass our forms and:


* change field and widget properties
* do so depending on run-time configuration (e.g. the database or
  settings)
* even if the inherited field type changes
* or the inherited options change
* and get an error if they reference a field that doesn't exist any more

Besides which, it's unnecessary, repetitive and unclear what one is doing.

 Anyhow, when it comes specifically to widgets, the Meta class already 
has a 'widgets' attribute already that lets you specify that.


Thanks for reminding me about that. It's a bit difficult to inherit 
through multiple levels of subclasses, and doesn't generate errors if one 
refers to a field or property that doesn't exist, but it meets most of my 
requirements.



I would sooner have "smart" Meta class attributes to perform this
behavior declaratively than to have to do it at the __init__ level:

class Meta:
    title__required = False
    programs__help_text = 'Hold down Ctrl to select multiple options'
    authors__required = False
    confidential__widget = AdminYesNoWidget
    uploader__required = False
    file__widget = AdminFileWidgetWithSize


Yes, that would work too, although it also doesn't generate errors if one
refers to a field or property that doesn't exist,


... and I don't like *that* particularly either.


Do you really dislike the idea of making form field properties settable 
after creation using @property and behave sensibly? It seems neat, simple, 
small, powerful and pythonic to me.


Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

--
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: Allow changing form field properties after form creation

[Nate Bragg]

They don't "have" to be replaced in a subclass in the way you showed.
Perhaps it isn't perfectly DRY, but whats so bad about naming the field
explicitly?  Anyhow, when it comes specifically to widgets, the Meta
class already has a 'widgets' attribute already that lets you specify that.

I would sooner have "smart" Meta class attributes to perform this
behavior declaratively than to have to do it at the __init__ level:

class Meta:
title__required = False
programs__help_text = 'Hold down Ctrl to select multiple options'
authors__required = False
confidential__widget = AdminYesNoWidget
uploader__required = False
file__widget = AdminFileWidgetWithSize

... and I don't like *that* particularly either.

Cheers,
Nate

On Thu, Apr 5, 2012 at 7:49 AM, Chris Wilson  wrote:

> Hi all,
>
> I've added this as a ticket but I wanted to make sure that the core and
> forms developers have a chance to see and interact with it, so I'm posting
> it here too. You can find the ticket at: <
> https://code.djangoproject.com/ticket/18064>
>
> Currently, if I want to tweak the properties of some fields in a
> ModelForm, I have to replace them in the subclass like this:
>
> {{{
> class DocumentForm(ModelForm):
>title =
> models.Document._meta.get_field('title').formfield(required=False)
>programs =
> models.Document._meta.get_field('programs').formfield(required=False)
>authors =
> models.Document._meta.get_field('authors').formfield(required=False)
>confidential =
> models.Document._meta.get_field('confidential').formfield(widget=AdminYesNoWidget)
>uploader =
> models.Document._meta.get_field('uploader').formfield(required=False)
>file =
> models.Document._meta.get_field('file').formfield(widget=AdminFileWidgetWithSize)
> }}}
>
> This is very bulky to just change some properties. The problem is that the
> field copies some of its properties into weird places like the widget
> during initialisation:
>
> {{{
> class Field(object):
>...
>def __init__(...)
>...
>if help_text is None:
>self.help_text = u''
>else:
>self.help_text = smart_unicode(help_text)
>widget = widget or self.widget
>if isinstance(widget, type):
>widget = widget()
>
># Trigger the localization machinery if needed.
>self.localize = localize
>if self.localize:
>widget.is_localized = True
>
># Let the widget know whether it should display as required.
>widget.is_required = self.required
>
># Hook into self.widget_attrs() for any Field-specific HTML
> attributes.
>extra_attrs = self.widget_attrs(widget)
>if extra_attrs:
>widget.attrs.update(extra_attrs)
>
>self.widget = widget
> }}}
>
> If we refactored this so that all the property initialisation was done in
> setters, then we could just write:
>
> {{{
> class DocumentForm(ModelForm):
>def __init__(...)
>self['title'].required = False
>self['programs'].help_text = 'Hold down Ctrl to select multiple
> options'
>self['authors'].required = False
>self['confidential'].widget = AdminYesNoWidget
>self['uploader'].required = False
>self['file'].widget = AdminFileWidgetWithSize
> }}}
>
> Which is more concise, much clearer, and does not override things
> unnecessarily.
>
> I can write the code, but first I want to:
>
> * see if any core developers object, to avoid wasting effort
> * know how to run the Django tests and which suite(s) I should be running
> * know where to put the tests.
>
> Cheers, Chris.
> --
> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
> Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
>
> Aptivate is a not-for-profit company registered in England and Wales
> with company number 04980791.
>
> --
> 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.

Allow changing form field properties after form creation

[Chris Wilson]

Hi all,

I've added this as a ticket but I wanted to make sure that the core 
and forms developers have a chance to see and interact with it, so I'm 
posting it here too. You can find the ticket at: 



Currently, if I want to tweak the properties of some fields in a 
ModelForm, I have to replace them in the subclass like this:


{{{
class DocumentForm(ModelForm):
title = 
models.Document._meta.get_field('title').formfield(required=False)
programs = 
models.Document._meta.get_field('programs').formfield(required=False)
authors = 
models.Document._meta.get_field('authors').formfield(required=False)
confidential = 
models.Document._meta.get_field('confidential').formfield(widget=AdminYesNoWidget)
uploader = 
models.Document._meta.get_field('uploader').formfield(required=False)
file = 
models.Document._meta.get_field('file').formfield(widget=AdminFileWidgetWithSize)

}}}

This is very bulky to just change some properties. The problem is that the 
field copies some of its properties into weird places like the widget 
during initialisation:


{{{
class Field(object):
...
def __init__(...)
...
if help_text is None:
self.help_text = u''
else:
self.help_text = smart_unicode(help_text)
widget = widget or self.widget
if isinstance(widget, type):
widget = widget()

# Trigger the localization machinery if needed.
self.localize = localize
if self.localize:
widget.is_localized = True

# Let the widget know whether it should display as required.
widget.is_required = self.required

# Hook into self.widget_attrs() for any Field-specific HTML 
attributes.

extra_attrs = self.widget_attrs(widget)
if extra_attrs:
widget.attrs.update(extra_attrs)

self.widget = widget
}}}

If we refactored this so that all the property initialisation was done in 
setters, then we could just write:


{{{
class DocumentForm(ModelForm):
def __init__(...)
self['title'].required = False
self['programs'].help_text = 'Hold down Ctrl to select multiple 
options'

self['authors'].required = False
self['confidential'].widget = AdminYesNoWidget
self['uploader'].required = False
self['file'].widget = AdminFileWidgetWithSize
}}}

Which is more concise, much clearer, and does not override things 
unnecessarily.


I can write the code, but first I want to:

* see if any core developers object, to avoid wasting effort
* know how to run the Django tests and which suite(s) I should be running
* know where to put the tests.

Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

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

[Tom Evans]

2012/4/4 Ł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?

Yes, they do. If I have a model with a field named 'address', I expect
that different instances of that model may have different values for
that attribute.

If on the other hand, I have a class with an attribute 'MALE', then I
expect that value to be immutable.

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

That makes no sense. If you want to see what value a choice has with
the proposed system, you have to work out precisely what ids will be
automagically assigned to a particular choice.

If you want to spot errors with the current system, you simply look
for choices with the same number. You don't have to work out what
number a choice is, it is explicitly there.

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

So, If I take your examples for groups, and annotate it with the
automagic assigned id:

> class License(Choices):
> COPYLEFT = Choices.Group(0)
> gpl_any = Choice("GPL, any")# id: 1
> gpl2 = Choice("GPL 2")  # id: 2
> gpl3 = Choice("GPL 3")  # id: 2
> lgpl = Choice("LGPL")   # id: 3
> agpl = Choice("Affero GPL") # id: 4
>
> PUBLIC_DOMAIN = Choices.Group(100)
> bsd = Choice("BSD") # id: 101
> public_domain = Choice("Public domain") # id: 102
>
> OSS = Choices.Group(200)
> apache2 = Choice("Apache 2")# id: 201
> mozilla = Choice("MPL") # id: 202

and now I decide that I want BSD licenses as a separate group to
public domain licenses, as they are not the same thing.

> class License(Choices):
> COPYLEFT = Choices.Group(0)
> gpl_any = Choice("GPL, any")# id: 1
> gpl2 = Choice("GPL 2")  # id: 2
> gpl3 = Choice("GPL 3")  # id: 2
> lgpl = Choice("LGPL")   # id: 3
> agpl = Choice("Affero GPL") # id: 4
>
> PUBLIC_DOMAIN = Choices.Group(100)
> public_domain = Choice("Public domain") # id: 101
>
> BSD = Choices.Group(150)
> bsd = Choice("BSD") # id: 151
>
> OSS = Choices.Group(200)
> apache2 = Choice("Apache 2")# id: 201
> mozilla = Choice("MPL") # id: 202

public_domain has changed from 102 => 101
bsd has changed from 101 => 151

These ids only change because ids in this system are handed out
automagically in order of appearance in the class, and grouping is
handled by order of appearance in the class.

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

So as above. Your counter will be "well, in those cases you need to
explicitly set an id on those choices". This relies on the person
making the changes realizing that there is magic happening, and take
that into account. That is dangerous compared to the current system,
where I would trust even a novice developer to change and move around
options.

This is because the current system is explicitly clear in what is happening.

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

So instead of MALE and FEMALE, Gender.m? No 

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

[Thomas Guettler]

Am 05.04.2012 10:03, schrieb Łukasz Rekucki:

On 5 April 2012 09:45, Thomas Guettler  wrote:

Hi,

I created a ticket, incl. patch

https://code.djangoproject.com/ticket/18062




While the example itself is useful, I don't really think Django's
documentation should state obvious facts about Python, especially
false ones.

...

Unless you defined MALE/FEMALE as globals too :) Otherwise you'll get
a NameError.


patch is fixed now. Unfortunately I can't modify the description in trac.

  Thomas

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

[GSOC Announce] One day remaining for applications

[Andrew Godwin]

Hi everyone,

Just a quick reminder that there's only one day left for GSOC 
applications - the deadline that they must be filed on the GSOC website 
by is April 6th, 19:00 UTC (roughly 30 hours from now).


Andrew

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

[Łukasz Langa]

Wiadomość napisana przez Stephen Burrows w dniu 5 kwi 2012, o godz. 07:41:

> I generally like this idea, except for the implicit integer ids based
> on declaration order.

Thanks for your input. I will add the ability to explicitly set .id values for 
each Choice in the next release.

> As people have said, it seems like just asking
> for data corruption.

Fair enough, although that does not match my experience.

> I'd much rather see implicit character ids based
> on the attribute name of the choice, analogous to django fields.


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


> Will you be making this project available as a third-party app?

pip install dj.choices

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

[Łukasz Langa]

Wiadomość napisana przez Łukasz Rekucki w dniu 5 kwi 2012, o godz. 10:03:

> I' sure you meant:
> 
> def greet(self):
>return {self.MALE: 'Hi, boy', self.FEMALE: 'Hi, girl.'}[self.gender]
> 
> Unless you defined MALE/FEMALE as globals too :) Otherwise you'll get
> a NameError.


Also, a minor diversity note: in real life gender choice is not binary.

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

[Łukasz Rekucki]

On 5 April 2012 09:45, Thomas Guettler  wrote:
> Hi,
>
> I created a ticket, incl. patch
>
> https://code.djangoproject.com/ticket/18062
>
>

While the example itself is useful, I don't really think Django's
documentation should state obvious facts about Python, especially
false ones.

>
> Am 04.04.2012 18:41, schrieb Adrian Holovaty:
>>
>>
>> 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]
>>

I' sure you meant:

def greet(self):
return {self.MALE: 'Hi, boy', self.FEMALE: 'Hi, girl.'}[self.gender]

Unless you defined MALE/FEMALE as globals too :) Otherwise you'll get
a NameError.

-- 
Łukasz Rekucki

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

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

[Thomas Guettler]

Hi,

I created a ticket, incl. patch

https://code.djangoproject.com/ticket/18062



Am 04.04.2012 18:41, schrieb 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



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