Interesting, you are right. It's still a little strange to me to be
accessing class attributes via the self object, but I suppose it is more
flexible than accessing them as User.MALE etc. which would make renaming
the class awkward.
Best,
Alex Ogier
On Apr 5, 2012 2:16 PM, "Łukasz Rekucki" wrote:
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'
> >> 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
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. D
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 Pyt
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
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 d
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
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')
I generally like this idea, except for the implicit integer ids based
on declaration order. As people have said, it seems like just asking
for data corruption. I'd much rather see implicit character ids based
on the attribute name of the choice, analogous to django fields.
Will you be making this
On Wed, Apr 4, 2012 at 5:18 PM, Łukasz Langa wrote:
> Wiadomość napisana przez Daniel Greenfeld w dniu 4 kwi 2012, o godz. 22:48:
>
> > On two occasions now I've had to do serious debugging on implementations
> done by other people who used a technique not dissimilar to what Łukasz
> proposes. In
Wiadomość napisana przez Daniel Greenfeld w dniu 4 kwi 2012, o godz. 22:48:
> +1 to what Adrian says.
Thanks for your input! :)
> On two occasions now I've had to do serious debugging on implementations done
> by other people who used a technique not dissimilar to what Łukasz proposes.
> In bo
On Wednesday, April 4, 2012 9:41:23 AM UTC-7, Adrian Holovaty wrote:
> 2012/4/3 Łukasz Langa :
> > Explicit choice values::
> >
> > GENDER_MALE = 0
> > GENDER_FEMALE = 1
> > GENDER_NOT_SPECIFIED = 2
> >
> > GENDER_CHOICES = (
> > (GENDER_MALE, _('male')),
> > (GENDER_FEMALE, _('femal
Wiadomość napisana przez Adrian Holovaty w dniu 4 kwi 2012, o godz. 18:41:
> Also, the fact that we *don't* have a sub-framework for this lets
> people do whatever they want -- including using the dj.choices module.
> So I am -1 on including this in Django proper.
Thank you for your feedback. As
Wiadomość napisana przez Tom Evans w dniu 4 kwi 2012, o godz. 18:40:
> The class definition grates. When we say things like:
>
> class Gender(Choices):
>male = Choice("male")
>
> That says to me that Gender.male is mutable. Ick.
Thanks for your feedback. Do model and form field definitions
Wiadomość napisana przez Daniel Sokolowski w dniu 4 kwi 2012, o godz. 17:52:
> The choice filtering could come in handy and in the end I don't see why this
> can't co-exist with django's standard way.
>
> WAY 4:
Nice but very verbose.
--
Best regards,
Łukasz Langa
Senior Systems Architecture
I agree we don't really gain anything from including this in core.
Django model utils[1] has a pretty solid implementation of a choice
abstraction.
[1] https://github.com/carljm/django-model-utils
On Wed, Apr 4, 2012 at 11:41 AM, Adrian Holovaty wrote:
> 2012/4/3 Łukasz Langa :
>> Explicit choic
2012/4/3 Łukasz Langa :
> Explicit choice values::
>
> GENDER_MALE = 0
> GENDER_FEMALE = 1
> GENDER_NOT_SPECIFIED = 2
>
> GENDER_CHOICES = (
> (GENDER_MALE, _('male')),
> (GENDER_FEMALE, _('female')),
> (GENDER_NOT_SPECIFIED, _('not specified')),
> )
>
> class User(models.Model
2012/4/3 Łukasz Langa :
> A nice HTML rendering of this proposal is available at:
> http://lukasz.langa.pl/2/upgrading-choices-machinery-django/
Disclaimer: all my code currently looks like 'Way 3'.
In general, I like it. There are a few things I don't like in it:
The class definition grates. Wh
ge-----
From: Łukasz Langa
Sent: Wednesday, April 04, 2012 9:15 AM
To: django-developers@googlegroups.com
Subject: Re: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Dan Poirier w dniu 4 kwi 2012, o godz. 14:08:
One nice addition would be to specify explicitly w
Wiadomość napisana przez Thomas Guettler w dniu 4 kwi 2012, o godz. 15:55:
> since most people have something like this in their code, a better solution
> should require
> only some additional characters.
Thank you for your feedback. I disagree since it wouldn't address any of the
original conc
Am 03.04.2012 21:31, schrieb Łukasz Langa:
A nice HTML rendering of this proposal is available at:
http://lukasz.langa.pl/2/upgrading-choices-machinery-django/
==
Upgrading the choices machinery for Django
==
...
Wiadomość napisana przez Dan Poirier w dniu 4 kwi 2012, o godz. 14:08:
> One nice addition would be to specify explicitly what .id a particular
> Choice should have. It would be useful in converting existing code that
> might not have chosen to number its choices the same way this proposal
> does
I like this - it solves something that's always bugged me.
One nice addition would be to specify explicitly what .id a particular
Choice should have. It would be useful in converting existing code that
might not have chosen to number its choices the same way this proposal
does by default. It looks
A nice HTML rendering of this proposal is available at:
http://lukasz.langa.pl/2/upgrading-choices-machinery-django/
==
Upgrading the choices machinery for Django
==
Specifying choices for form fields and models cur
25 matches
Mail list logo
