FEATURE REQUEST: Choices overriding in a classes, which inherit abstract class

[Anton Ponomarenko]

>From the doc: "Abstract base classes are useful when you want to put some 
common information into a number of other models". In my current project I 
put all common fields in abstact class, but those fields that use 'choice' 
option may have different choices in different child classes.

Code Example:

class AbstractProfile(models.Model):
# Basic choices, which may vary in different classes
PRIVACY_CHOICES = (
(1, _('all')),
(2, _('no one')),
)

title = models.CharField(_('title'), max_length=30)
info = models.TextField(_('information'), max_length=500, blank=True)
info_privacy = models.IntegerField(_('show information to'), default=1, 
choices=PRIVACY_CHOICES)

city = models.CharField(_('location'), max_length=30, blank=True)
address = models.CharField(_('address'), max_length=30, blank=True)
address_privacy = models.IntegerField(_('show address to'), default=1, 
choices=PRIVACY_CHOICES)

class Meta:
abstract = True

class UserProfile(AbstractProfile):
PRIVACY_CHOICES = (
(1, _('all')),
(2, _('friends')),
(3, _('friends of friends')),
(4, _('only me')),
)

GENDER_CHOICES = (
(1, _('man')),
(2, _('woman')),
)

title = None

first_name = models.CharField(_('first name'), max_length=30, blank=True
)
last_name = models.CharField(_('last name'), max_length=30, blank=True)
names_privacy = models.IntegerField(_('show names to'), default=1, 
choices=PRIVACY_CHOICES)

birth_date = models.DateField(_('birth date'), null=True, blank=True)
birth_date_privacy = models.IntegerField(_('show birth date to'), 
default=1, choices=PRIVACY_CHOICES)

gender = models.IntegerField(_('gender'), null=True, blank=True, choices
=GENDER_CHOICES)

avatar = models.ImageField(upload_to='users/avatar', null=True, blank=
True)

class CompanyProfile(AbstractProfile):
PRIVACY_CHOICES = (*** new choices, which are different to those which 
are in abstract class ***)

class TeamProfile(AbstractProfile):
pass

There is a proposition to add to the 'class Meta' a new attribute, which 
lets to define, whether to use CHOICES from abstract class or use those 
which exists in the current class, something like:
class UserProfile(AbstractProfile):
PRIVACY_CHOICES = (
(1, _('all')),
(2, _('friends')),
(3, _('friends of friends')),
(4, _('only me')),
)

GENDER_CHOICES = (
(1, _('man')),
(2, _('woman')),
)

title = None

first_name = models.CharField(_('first name'), max_length=30, blank=True
)
last_name = models.CharField(_('last name'), max_length=30, blank=True)
names_privacy = models.IntegerField(_('show names to'), default=1, 
choices=PRIVACY_CHOICES)

birth_date = models.DateField(_('birth date'), null=True, blank=True)
birth_date_privacy = models.IntegerField(_('show birth date to'), 
default=1, choices=PRIVACY_CHOICES)

gender = models.IntegerField(_('gender'), null=True, blank=True, choices
=GENDER_CHOICES)

avatar = models.ImageField(upload_to='users/avatar', null=True, blank=
True)

class Meta:
use_choices = [PRIVACY_CHOICES]

Possible variants:
Variant A: Use CHOICES from abstract class - do not add anything to 'class 
Meta'
Variant B: Use CHOICES from current class instead of abstract class - add:
class Meta: 
use_choices = [*** list of choices of current class **]

Variant C: Same as B, but change format a bit:
class Meta: 
use_choices = ((ABSTRACT_CHOICES_NAME1, CURRENT_CLASS_CHOICES_NAME1), (
ABSTRACT_CHOICES_NAME2, CURRENT_CLASS_CHOICES_NAME2),)
just in case, if a developer for some reasons have different names of 
choices

This feature lets to have development process as DRY as possible, which is 
the reason why abstract class exists.

In order to solve it, currenty I use the next code:
# models.py
class UserProfile(AbstractProfile):
PRIVACY_CHOICES = (
(1, _('all')),
(2, _('friends')),
(3, _('friends of friends')),
(4, _('only me')),
)

# NEW PIECE OF CODE
def __init__(self, *args, **kwargs):
def get_class_attrs(cls):
return re.findall(r'\w+(?=[,\)])', cls.__dict__['__doc__'])

super(UserProfile, self).__init__(*args, **kwargs)

all_fields = get_class_attrs(UserProfile)
for each_field in all_fields:
# all fields with '_privacy' in the name have 'choice' option
if '_privacy' in each_field:
self._meta.get_field(each_field).choices = self.
PRIVACY_CHOICES

default_privacy_choice = self.PRIVACY_CHOICES[0][0]
if self._meta.get_field(each_field).default != 
default_privacy_choice:
self._meta.get_field(each_field).default = 
default_privacy_choice
# END OF NEW PIECE OF CODE

title = None
*** rest fields ***

# forms.py
class UserProfileForm(forms.ModelForm):
class 

Re: Does the javascript test runner need attention?

[Tim Graham]

Trey Hunner said [0], "Blanket and qunit are the only real requirements 
here. We may be able to switch away from Grunt and use those together in a 
more manual fashion so requirements can be upgraded easily."

[0] https://github.com/django/django/pull/4889#issuecomment-219921988

On Thursday, August 25, 2016 at 9:31:08 AM UTC-4, Josh Smeaton wrote:
>
> Hi All,
>
> While building out a vagrant image for running django's tests (plug: 
> https://github.com/django/django-box) I came across a problem trying to 
> run the javascript tests as defined by the tox.ini file. It ended up being 
> the same problem as raised in https://code.djangoproject.com/ticket/25803. 
> The fix to that ticket was to update the package.json dependencies listing 
> npm as < 3.0.0, but I'm wondering if there's a longer term solution we're 
> going to need to look at.
>
> https://github.com/ModelN/grunt-blanket-qunit appears to be abandoned and 
> is probably the main cause of us requiring npm version 2. Maybe we could 
> look at separate packages for generating code coverage and running qunit 
> tests? Does that sound right? I'm happy to open a ticket to track this, but 
> just wanted to see if it's needed or already on someones radar.
>
> Cheers
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d41a4227-9979-47b9-8260-ae45d15415ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Take index type into account in inspectdb command

[akki]

Ticket to add support for introspection of index type 
- https://code.djangoproject.com/ticket/27097



On Friday, 19 August 2016 21:03:00 UTC+5:30, Tim Graham wrote:
>
> I think if we do a similar thing like we do for field introspection 
> (outputting a comment like "# This field type is a guess" next to unknown 
> fields) it would be okay. The comment might say the backend doesn't support 
> index type introspection. Let's put out a call for help to try to get index 
> introspection done on the other databases for 1.11.
>
> On Wednesday, August 17, 2016 at 12:01:51 PM UTC-4, akki wrote:
>>
>> Hi
>>
>> Currently the inspectdb command doesn't take the database indexes into 
>> account (Ticket - #27060 
>> ). While working on 
>> adding this feature, there was some confusion related to the inclusion of 
>> the index type.
>>
>>
>> I have implemented this feature here 
>>  but since Django doesn't 
>> support introspection of the type of index, currently the generated models 
>> have the default (B-tree) index no matter what the type of the actual index 
>> in the database may be. So I would like seek some advice on whether it 
>> would be a good idea to move ahead with this approach with a comment at the 
>> beginning of the generated file with the other comments 
>> 
>>  and 
>> integrate this basic implementation into Django (with an update on the 
>> ticket and keeping the ticket open, maybe?).
>>
>> Or should this be kept on a hold until Django supports introspection of 
>> the index type for it's backends (PostgreSQL has this feature with some 
>> concerns 
>> about the design 
>> ) 
>> and be done correctly all at once. Once that happens we would either use 
>> the correct index type if it is supported by Django, else add a comment 
>> informing that the index type is not a match and should be created manually.
>>
>>
>> Please let me know if any other clarification is required on this. Thanks 
>> for any help.
>>
>> Regards
>> akki
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4f7e7d3a-77d2-4a11-aab1-568e1a0352b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SearchQuery concatenation (`&` and `|`) is either broken or documentation incomplete

[Josh Smeaton]

Hi Nicola,

Without a lot of familiarity of SearchQuery, in particular, it looks like a 
bug to me. SearchQuery defines its own operators to work around the 
limitation in Combinable, but fails to take into account that when two 
SearchQuery instances are combined, you're returned a CombinedExpression 
(containing SearchQueries). SearchVector *does* take this into 
consideration though, and provides it's own Combinable Mixin, so I wonder 
if the limitations for SearchQuery aren't on purpose.

Marc Tamlyn would probably have a good idea if this was an oversight or 
deliberate.

The fix would be to define a SearchQueryCombinable Mixin that looks very 
similar to SearchVectorCombinable, and override the various __or__ and 
__and__ methods, as the SearchQuery type does itself. Hope that helps?

Regards,

On Thursday, 25 August 2016 21:30:06 UTC+10, Nicola wrote:
>
> Dear Django-Developers,
>
> We just started using the new search ability that landed in Django 1.10 
> (using postgres).
>
> Reading the documentation[1], I thought I can use `&` and `|` to join 
> search queries as I like[2]. This is not the case, which can easily be seen 
> by creating a the test-case with two ampersands or pipes[3]. 
>
> I would not expect that the test-cases pass, but they error out: 
> `NotImplementedError: Use .bitand() and .bitor() for bitwise logical 
> operations.`.
>
> To me this is not the expected behaviour, but maybe I deducted the wrong 
> conclusions from reading the documentation.
>
> My unanswered questions:
>
>- Is it a bug?
>- Is this the intended behaviour?
>   - If so: what needs to be done to get a note into the 
>   documentation, that only one ampersand/pipe is allowed?
>
> Thank you for your time and effort for this excellent framework!
>
> Kind Regards,
>
> Nicola
>
>
> [1]: 
> https://docs.djangoproject.com/en/1.10/topics/db/search/#postgresql-support 
> and https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/search/
> [2]: 
> https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/search/#searchquery
> [3]: https://github.com/django/django/compare/master...hixi:master
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/31548201-3d01-4318-8165-47cad2afa1fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

SearchQuery concatenation (`&` and `|`) is either broken or documentation incomplete

[Nicola]

Dear Django-Developers,

We just started using the new search ability that landed in Django 1.10 
(using postgres).

Reading the documentation[1], I thought I can use `&` and `|` to join 
search queries as I like[2]. This is not the case, which can easily be seen 
by creating a the test-case with two ampersands or pipes[3]. 

I would not expect that the test-cases pass, but they error out: 
`NotImplementedError: Use .bitand() and .bitor() for bitwise logical 
operations.`.

To me this is not the expected behaviour, but maybe I deducted the wrong 
conclusions from reading the documentation.

My unanswered questions:

   - Is it a bug?
   - Is this the intended behaviour?
  - If so: what needs to be done to get a note into the documentation, 
  that only one ampersand/pipe is allowed?
   
Thank you for your time and effort for this excellent framework!

Kind Regards,

Nicola


[1]: 
https://docs.djangoproject.com/en/1.10/topics/db/search/#postgresql-support 
and https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/search/
[2]: 
https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/search/#searchquery
[3]: https://github.com/django/django/compare/master...hixi:master

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ab630b97-6a9b-4b2e-aaed-77a801f40681%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

[Ian Foote]

I think the consensus here is to not add the extra commit, so I've 
closed the ticket as wontfix. 
(https://code.djangoproject.com/ticket/16735#comment:26)


Ian

On 20/08/16 15:24, Josh Smeaton wrote:
Just as an additional data point - most expressions that accept 
strings internally convert them to F(), so it's not entirely 
inconsistent with other behaviour. I don't really have a preference 
here though, so happy to go with what the majority prefer.


On Saturday, 20 August 2016 04:59:10 UTC+10, Loïc Bistuer wrote:

I prefer enforcing .values(alias=F(’something’)), to me
.values(alias=‘something’) reads as the equivalent of
.values(alias=Value(‘something’)).

-- 
Loïc


> On Aug 20, 2016, at 1:04 AM, Tim Graham  wrote:
>
> We now have support for expressions in values()/values_list() --
thanks Ian! With the new commit [0], aliases can be created like
this: .values(alias=F('field'))
>
> Ian has offered an additional commit in the pull request [1] to
allow .values(alias='field') (without the F() expression) to
automatically wrap the string in an F() expression to create an
alias. I'm not sure whether or not to accept that patch as I think
I prefer the look of the explicit F() rather than magically
treating strings as F() expressions. What do you think?
>
> [0]

https://github.com/django/django/commit/39f35d4b9de223b72c67bb1d12e65669b4e1355b



> [1] https://github.com/django/django/pull/7088

>
> On Wednesday, November 25, 2015 at 7:24:22 PM UTC-5, Josh
Smeaton wrote:
> I would really like two things for values to support.
>
> 1. Aliases .values(alias='field');
> 2. Expressions .values(alias=F('field'))
>
> I think these two features are absolute must haves, and the
syntaxes above are already standard in other parts of the ORM.
>
> If someone can come up with a way to support nested relations
while supporting the above syntax, then I'd be OK with that. But
at the moment, I'm firmly in the "this is the responsibility of a
serialiser" camp. I'm not convinced Django needs to support nested
objects at all. Is this something you could implement with your
own queryset method on a manager? Is this maybe something we could
look at creating a new queryset method called .values_dict() ?
>
> If it weren't for backwards compatibility, I'd suggest that
referencing the related object would automatically nest that
object. That would differentiate between the id and the field
values('related_id', 'related') -> '{"related_id": 1, "related":
{"id": 1, ..}}'.
>
> If there's (rough) consensus on having nested objects, then we
could allow something like: .values(..., ..., nested=('related',
'related__otherrelated')). If the value of nested is an iterable
then assume we're nesting, otherwise nested is an alias for the
field. I don't particularly like overloaded kwargs, but we're just
guarding against someone wanting to alias as "nested" which we
could call out in docs anyway.
>
> The more I think about this the more I think nesting and aliases
within a nest should probably be done in a different queryset
method. Or just handled by a serialiser. If you want more requests
per second, then add some more backends.
>
> --
> You received this message because you are subscribed to the
Google Groups "Django developers (Contributions to Django itself)"
group.
> To unsubscribe from this group and stop receiving emails from
it, send an email to django-develop...@googlegroups.com
.
> To post to this group, send email to
django-d...@googlegroups.com .
> Visit this group at
https://groups.google.com/group/django-developers
.
> To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/00d4305c-175e-415c-b446-a53c7d15c00d%40googlegroups.com

.

> For more options, visit https://groups.google.com/d/optout
.

--
You received this message because you are subscribed to the Google 
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-developers+unsubscr...@googlegroups.com 
.
To post to this group, send email to 
django-developers@googlegroups.com 
.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit