Query about inheritance clash in models

[Dheerendra Rathor]

I've a specific set of models:

class Parent(models.Model):
pass


class ChildA(Parent):
pass


class ChildB(Parent):
pass


Here Parent has fields:
(,
 ,
 )

and ChildB has fields:
(,
 )

so fields childa and childb are not inherited in ChildB, which is normal 
and expected. But adding a field '*childa*' in ChildB leads to E006 clash 
with a field in parent. But IMHO there should not be any clash reported as 
ChildBInstance.childa is not a valid field without the presence of local 
childa field. 

-- 
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/e6376613-5dbf-4ba7-bc9a-81611f27d074%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

3 level nested prefetch is not working as expected on Django 1.8.x

[Dheerendra Rathor]

Posting this from 
django-users https://groups.google.com/forum/#!topic/django-users/v3KelvexqiI.

Three level nested prefetch with custom queryset throws an Attribute Error. 
> It works perfectly fine on Django 1.9 but I was unable to find release 
> notes or bug fix notes of the same. 
>
> To reproduce: 
> 1. Install Django 1.8.6+
> 2. Add models from 
> https://github.com/DheerendraRathor/Django-bugs/blob/master/prefetch_one/models.py
> 3. Run the script from 
> https://github.com/DheerendraRathor/Django-bugs/blob/master/prefetch_one/script.py
>
> It throws: AttributeError: Cannot find 'videos' on QuizMarker object, 
> 'videos__markers__quiz__quiz_histories' is an invalid parameter to 
> prefetch_related()
> however, running the same with Django 1.9 works fine as expected. 
>

 

-- 
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/837377ce-28c1-41ba-a08d-f6a719c0db04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

[Dheerendra Rathor]

On Wed, 10 Feb 2016 at 13:55 Andy Baker  wrote:

> I can't help but feel that the "admin is very rudimentary and hard to
> customize" is perpetually overplayed by many in the community. Maybe I'm
> suffering Stockholm Syndrome but I'd like to raise a dissenting voice.
>
> I find it the quickest and most efficient way to provide an admin
> interface for staff users. It's remarkably easy to customize in my view
> (and I've done a heck of a lot of it). If it didn't exist I'd have to
> invent something damn similar. :)
>
> More importantly - it's not an either/or decision. I always recommend
> starting with the admin - use the available hooks and means of
> customization and when you really, truely hit a brick wall - then remember
> "It's just Django" - drop down to a custom view that uses the admin base
> templates and CSS and easily integrates with other admin pages. The beauty
> of this is that you can carry on using the admin for everything else where
> it still provides easy wins.
>
> Warning people away means they are less likely to discover the many simple
> customization hooks and they are more likely to spend time reinventing the
> wheel.
>
> If the admin was truly as limited as some make it out to be, then one of
> the many attempts to replace it would have gained momentum. I'm not saying
> it couldn't be replaced with something better - but it's far from being
> something we should cover in warnings and caveats.
>
> Sigh. I perpetually intend to write tutorials to help demystify admin
> customization - but I've sadly perpetually failed to find the time...
>

It comes to my  mind many times to create a video tutorial for advance
Django including customizing admin and other advance part of Django like
complex querysets (with F, Q etc).
We can work together on this to create nice tutorials.

On Tuesday, 9 February 2016 23:25:20 UTC, Tim Graham wrote:
>>
>> The introduction to the admin in the docs [0] reads:
>>
>> "One of the most powerful parts of Django is the automatic admin
>>> interface. It reads metadata in your model to provide a powerful and
>>> production-ready interface that content producers can immediately use to
>>> start adding content to the site."
>>>
>>
>> I've proposed [1] changing it to:
>>
>> "One of the most powerful parts of Django is the automatic admin
>>> interface. It reads metadata from your models to provide a quick and
>>> rudimentary interface where trusted users can manage content on your site.
>>>
>>>
>>> The admin has many hooks for customization but beware of trying to use
>>> those hooks exclusively. If your needs outgrow what the admin provides, it
>>> may be simpler to write your own views. The admin’s recommended use is as
>>> an organization’s internal management tool. It’s not intended for building
>>> your entire front end around."
>>>
>>
>> However several reviewers have made comments like "I worry that the
>> description of the Admin sells it short. The Admin is actually brilliant
>> kit and works as advertised." and "Downgrading Django's admin from
>> "powerful and production ready" to "quick and dirty [old wording]" is very
>> harsh... And I fear this will not only lower user's expectations, but also
>> dev's carefulness!"
>>
>> I think part of the reason I raise this is that I'm getting weary of
>> adding hook after hook for customizing every little thing. I worry we'll
>> end up with an unmaintainable mess at some point. The latest proposal that
>> has me thinking about this adds ModelAdmin.orderable_by and 
>> ModelAdmin.get_orderable_by()
>> for the use case of disabling sorting of a column in the change list [2].
>> This topic also came up in the discussion of whether or not to add
>> ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done
>> yet). There's also an open question about whether or not to add a view
>> permission [4]. I don't want to discuss each of these decisions on this
>> thread but rather the broader question of whether putting a lot of effort
>> in this area is a direction we should pursue. I know there have been some
>> proposals of "admin2" but realistically I think the admin has too many
>> customizations points such that superseding it with something new and
>> innovative won't be feasible from a backwards compatibility standpoint.
>>
>> [0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
>> [1] https://github.com/django/django/pull/6104
>> [2] https://github.com/django/django/pull/6107
>> [3]
>> https://groups.google.com/d/topic/django-developers/WrnhmTyLHuY/discussion
>> [4]
>> https://groups.google.com/d/topic/django-developers/X7YEGB9KJNc/discussion
>>
> --
> 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 

Re: thinking about the admin's scope and its description in the docs

[Dheerendra Rathor]

On Tue, 9 Feb 2016 at 23:25 Tim Graham  wrote:

> The introduction to the admin in the docs [0] reads:
>
> "One of the most powerful parts of Django is the automatic admin
>> interface. It reads metadata in your model to provide a powerful and
>> production-ready interface that content producers can immediately use to
>> start adding content to the site."
>>
>
> I've proposed [1] changing it to:
>
> "One of the most powerful parts of Django is the automatic admin
>> interface. It reads metadata from your models to provide a quick and
>> rudimentary interface where trusted users can manage content on your site.
>
>
How about quick and powerful?

> The admin has many hooks for customization but beware of trying to use
>> those hooks exclusively. If your needs outgrow what the admin provides, it
>> may be simpler to write your own views. The admin’s recommended use is as
>> an organization’s internal management tool. It’s not intended for building
>> your entire front end around."
>>
> What I have understood from using admin for years is that customizing
admin is really tough for new users, but for power users admin is a really
handy tool. I've written way complex user permission handling using admin
tool which could have given a hard time if written in normal django views.


> However several reviewers have made comments like "I worry that the
> description of the Admin sells it short. The Admin is actually brilliant
> kit and works as advertised." and "Downgrading Django's admin from
> "powerful and production ready" to "quick and dirty [old wording]" is very
> harsh... And I fear this will not only lower user's expectations, but also
> dev's carefulness!"
>
> I think part of the reason I raise this is that I'm getting weary of
> adding hook after hook for customizing every little thing. I worry we'll
> end up with an unmaintainable mess at some point. The latest proposal that
> has me thinking about this adds ModelAdmin.orderable_by and 
> ModelAdmin.get_orderable_by()
> for the use case of disabling sorting of a column in the change list [2].
> This topic also came up in the discussion of whether or not to add
> ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done
> yet). There's also an open question about whether or not to add a view
> permission [4]. I don't want to discuss each of these decisions on this
> thread but rather the broader question of whether putting a lot of effort
> in this area is a direction we should pursue. I know there have been some
> proposals of "admin2" but realistically I think the admin has too many
> customizations points such that superseding it with something new and
> innovative won't be feasible from a backwards compatibility standpoint.
>
> Yes admin do provide customization for every little thing. IMHO, the power
of admin lies in this. A new admin might work but I fear power users won't
like it if it does not provide all those little customization like current
admin.

> [0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
> [1] https://github.com/django/django/pull/6104
> [2] https://github.com/django/django/pull/6107
> [3]
> https://groups.google.com/d/topic/django-developers/WrnhmTyLHuY/discussion
> [4]
> https://groups.google.com/d/topic/django-developers/X7YEGB9KJNc/discussion
>
> --
> 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/72ecc667-1dba-432e-a749-dca214fa77b5%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 
https://groups.google.com/d/msgid/django-developers/CAByqUgjZBxpzM5cXevF5a3Pcmj-Z5wQd_%3D8uwnvkfFqrMv%3D7nw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the primary key of Django models

[Dheerendra Rathor]

Yes you can keep custom primary key. Pass `primary_key=True` in your model
and Django won't create a primary key for that model.

Here are relevant docs:
https://docs.djangoproject.com/en/1.9/ref/models/fields/#django.db.models.Field.primary_key

On Fri, 5 Feb 2016 at 20:52 Uri Even-Chen  wrote:

> To django-developers@googlegroups.com,
>
> I'm a Django user and I'm working on converting Speedy Net from PHP to
> Django. I would like to know if it's possible in Django to change the
> primary key of Django models, such as User? I don't like the auto-increment
> default primary key, it doesn't make sense, and I want to use the primary
> key of users and pages also in urls. And therefore I decided that the id of
> users and pages, causes, groups and events on Speedy Net will be 15
> randomly generated digits. Users who already created accounts and pages on
> Speedy Net (with PHP) already have a 15-digits id, and I want to preserve
> this number when converting Speedy Net to Django. Is it possible? I don't
> want the id/primary key to be short (such as zuck's id on Facebook -
> https://www.facebook.com/messages/4) but 15-digits long.
>
> Thanks,
> Uri.
>
> *Uri Even-Chen*
> [image: photo] Phone: +972-54-3995700
> Email: u...@speedy.net
> Website: http://www.speedysoftware.com/uri/en/
> 
> 
>   
>
>
> -- Forwarded message --
> From: Uri Even-Chen 
> Date: Thu, Feb 4, 2016 at 6:20 PM
> Subject: ID for users of Speedy Net
> To: django-us...@googlegroups.com
> Cc: speedy-mail-softw...@googlegroups.com
>
>
> To django-us...@googlegroups.com,
>
> I'm working on the next version of Speedy Net ,
> which will be based on Django 1.9.2 and Python 3.5 / 3.4. You can see the
> specification of Speedy Net on
> https://github.com/urievenchen/speedy-net/tree/master/speedy_net/specifications
>  (the
> file is System Requirements Specification - Speedy Net.txt). The old code
> is in PHP and can be found on
> https://www.assembla.com/spaces/speedynet/subversion/source (all the
> Speedy Net projects are free software and open source). According to my
> specification, each user will have a unique ID of 15 digits (a
> number between 100,000,000,000,000 and 999,999,999,999,999, randomly
> generated), which will be unique over the system (of users, pages, groups,
> causes and events). And each user will have a username, and pages, groups
> and causes may also have an optional username (it's called "username" also
> on Facebook).
>
> So my question is, can I make this random ID the primary key of the User
> model? I don't want users to have 2 ids - one for Django and one of Speedy
> Net, it doesn't make sense. I want the id to be the same and unique. I also
> want to have an Id model to prevent a page and a user (for example) to have
> the same ID. And a Username model to prevent them from having the same
> username. Is it possible to do it with Django 1.9.2?
>
> By the way, if you want to help me develop Speedy Net, Speedy Composer,
> Speedy Match or Speedy Mail, please let me know. If you want you can also
> join Speedy Net and grab yourself a username at Speedy Net. I'm also
> sending a copy of this message to speedy-mail-softw...@googlegroups.com,
> the list of developers of the Speedy Net projects.
>
> I have another, off-topic question. Anyone knows how I can create a
> company in Switzerland, and how much does it cost? Any links to lawyers who
> can do it for me? I decided to host Speedy Net in Switzerland, because of
> the privacy laws there, and I prefer a Swiss company for the same reason
> (Israel is much less advanced in privacy than Europe and Switzerland). I'm
> a resident and citizen of Israel, with an option to become a Spanish
> citizen too. And I don't want to host private information of people in
> Israel.
>
> Thanks,
> Uri.
>
> *Uri Even-Chen*
> [image: photo] Phone: +972-54-3995700 <+972-54-3995700>
> Email: u...@speedy.net 
> Website: http://www.speedysoftware.com/uri/en/
> 
> 
> 
>   
>
> --
> 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/CAMQ2MsGMip-WreMzjrpZFxJUB3edJz9RQoiMLoo5tEwjU-7pfw%40mail.gmail.com
> 

Re: Remove null assingment check for non-nullable fields?

[Dheerendra Rathor]

With respect to rationale 2:
It makes sense to remove this check as database handle these checks very
well. And just like uniqueness checks, it is nice to let database do its
work.

With respect to rationale 1:
Since this behaviour will ask developers to change exception catching from
ValueError to IntegrityError, I guess this will be a huge pain for
developers to migrate considering how lazy we developers are.

In my opinion it is good to remove this check in future version (probably
Django 2.0) and for now a RemovedInDjango1xxWarning can be showed with
ValueError check.

On Tue, 2 Feb 2016 at 23:26 Tim Graham  wrote:

> There's a proposal to remove this behavior:
>
>
> >>> obj.fk = None
> ValueError('Cannot assign None: "Obj.fk" does not allow null values.)
>
>
> (i.e. no more exception if you assign None to a non-nullable foreign key)
>
>
> Rationale presented on the ticket [1]:
>
>- Conceptually it is a programmer's responsibility to validate the
>data assigned to foreign key in a right moment - not necessarily during
>assignment to the model field.
>- This behavior is not symmetrical to other database-related
>constraints as for example unique=True which is deferred to save()
>method (raising IntegrityError
>) or full_clean()
>method (raising ValidationError).
>- In #13776  the decision
>was made that a None value for foreign key field with null=False and
>corresponding form field with required=False should be valid. It means
>that after model instantiation by such a form, the value of a given field
>is empty or just unset (not defined). Whatever the state is, it doesn't
>matter. It shows only that currently discussed check does *not*
>prevent in 100% against having foreign key field with null=False set
>to None. It undermines the legitimacy of presence for the discussed
>check.
>
> Any concerns with this?
>
>
> Its removal helps fix an edge case that regressed in Django 1.8 where if
> you have a model field with blank=False but required=False on the form
> field, an empty form value will be silently ignored and won't overwrite a
> model instance's value. I think it's a sufficient edge case, however, that
> it's not worth backporting this change (if accepted).
>
>
> [1] https://code.djangoproject.com/ticket/25349
>
> --
> 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/a79c63a4-abdf-4cbd-bf96-a4bc2d5b537b%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 
https://groups.google.com/d/msgid/django-developers/CAByqUgiMZgB2LxDyQLW%2B5tLezu8omJihBZExScuSaVPFG4OMYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: add new template tag "age"

[Dheerendra Rathor]

If we ever need to implement age filter, I would rather suggest for
modification of naturaltime in django.contrib.humanize to take an optional
parameter (age = True).

On Tue, 10 Nov 2015 at 01:22 Tim Graham  wrote:

> For questions of whether or not to include something like this in core, my
> own rule of thumb is, "Is this difficult to implement as a third-party
> package? If not, do more than ~80% of sites need this feature?" If the
> answer to both questions is "no" (which is the case here, in my opinion),
> then I don't favor including it in Django.
>
> For historic reasons we have some filters like phone2numeric which likely
> don't meet this criteria. I don't see much benefit to deprecating them, but
> let's not add more. Other opinions welcome.
>
>
> On Monday, November 9, 2015 at 2:43:46 PM UTC-5, Paulo Maciel wrote:
>>
>> My proposal is to add a new template tag "age": {{ birthday|age }}.
>> I think it is a common need for many users know the age from a date.
>>
>>
>> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/d9ce1b89-1af0-4038-816f-24e13d25a666%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAByqUgjS8nzfuwa_CApjAky-LTmADdukU9sKL3bLyh5ogA1oeA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: User.username max_length 254

[Dheerendra Rathor]

Hello All,

Since username length is going to increased from 30 to 254 (PR #5497 
), I personally think 
first_name and last_name field length should be increased as well. 
Practically many first names are of length > 30, this is quite common in 
southern India 
(https://www.quora.com/Why-are-South-Indian-names-often-long). IMHO these 
fields should be increased to 254 as well. 

On Saturday, 7 February 2015 06:40:02 UTC+5:30, Collin Anderson wrote:
>
> Hi All,
>
> I was reminded by:
> Allow shadowing of abstract fields 
> https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
> and https://code.djangoproject.com/ticket/24288 (Custom User Models for 
> small tweaks).
>
> Could we reopen https://code.djangoproject.com/ticket/20846 and increase 
> User.username max_length to 254?
>
> Personally, that's the only thing I've ever needed to change about my User 
> class. I just need it long enough to hold email addresses. I've seen many 
> other people wanting the same thing.
>
> In 1.8 we migrated the length of EmailField from 75 to 254, so it should 
> be almost™ as easy to change the username field.
>
> If needed, we could keep the 30-character limit on UserCreationForm and 
> UserChangeForm for backwards compatibility. The limit in the database is 
> the real killer :) Though, consistency is also nice.
>
> Thanks,
> Collin
>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ef2b200d-44ba-4b98-b199-35db9f754425%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should contrib.auth include support for 2fa out of the box?

[Dheerendra Rathor]

Other then u2f and TOTP, I'll favour for email and sms (using external api
like twilio) based OTP as well. Keeping different pluggable backends will
be better in my opinion.

On Tue, 27 Oct 2015 at 07:01 Russell Keith-Magee 
wrote:

>
> +1. Sounds like a great idea to me.
>
> Russ %-)
>
> On Tue, Oct 27, 2015 at 1:22 AM, Tim Graham  wrote:
>
>> On Trac [1], Alex says, "Django did a tremendous service to its users by
>> making strong password hashing be the default. The world is pushing
>> forward, and now 2fa is the next standard that many sites fail to meet.
>> Django should include support for 2fa out of the box, ideally with support
>> for both u2f and TOTP (Google Authenticator)."
>>
>>
>> Doing a quick search, I found
>> https://github.com/Bouke/django-two-factor-auth as a possible existing
>> implementation that might be a starting point if we decide to integrate
>> something. What do you think? One sticking point could be that it uses a
>> ThreadLocals middleware. I didn't look to see how "necessary" that is.
>>
>>
>> [1] https://code.djangoproject.com/ticket/25612
>>
>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/5ae7be8e-949c-4074-b613-04ca2a62fed8%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq8494WzyFUS%2B4J93dQfge64HkmSOmWK9Lg5dyuqmhmxpUOA%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAByqUggu2tcBY13DQr9fWuQJJeFF6Hs1VG%2BdFfn465TH%3DCULrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Python 3.5 Support in Django 1.8.x?

[Dheerendra Rathor]

In my opinion adding 3.5 support to 1.8 makes sense since 1.8 is LTS and by
the end of 2018 we'll have python 3.6 and 3.7 as well

On Sat, 24 Oct 2015 at 03:28 Marc Tamlyn  wrote:

> FWIW, I think we should add 3.5 support to 1.8.
>
> On 23 October 2015 at 17:08, Tim Graham  wrote:
>
>> Officially Django 1.8 doesn't support Python 3.5. In practice, I think it
>> probably works. See details in
>> https://code.djangoproject.com/ticket/25502 about why the 1.8 test suite
>> doesn't pass with Python 3.5. We could probably change that if there is
>> sufficient interest, however, I'm not aware of a precedent of adding Python
>> version support in a major release retroactively.
>>
>> On Friday, October 23, 2015 at 10:48:54 AM UTC-4, Tim Allen wrote:
>>>
>>> Since Django 1.9 will support Python 3.5, I was wondering if there are
>>> any plans to support Python 3.5 in Django 1.8, since it is an LTR.
>>>
>>> I did a cursory search and didn't find anything stating yay or nay. I'm
>>> going to assume 1.8 only support 3.4 for now, as I've had issues with
>>> Python 3.5 (if, on the other hand, there will be support, I'll report this
>>> bugs in detail).
>>>
>>> Can someone give me an answer or point me to a relevant discussion I may
>>> have missed? Thank you.
>>>
>>> Regards,
>>>
>>> Tim
>>>
>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/eb6e94aa-eedf-4fff-9d3b-f7ba424c0a71%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1GkMrKnJn9J0HHTqcauMF4gSMH-Bwd-n2beSrCCr9rixg%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAByqUghkG5FqfMWCLmxpdVMxcD%3DnfvXtDT6DH%3Db7TKGQVyLoSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why passing request, *args, **kwargs in dispatch method for generic views

[Dheerendra Rathor]

On Friday, 23 October 2015 19:31:07 UTC+5:30, Marc Tamlyn wrote:
>
> This would cause too much churn for user code - there are millions of CBVs 
> in the wild with customised dispatch/get/post/etc methods which expect 
> these variables and perhaps use them directly. Unfortunately this ship has 
> sailed.
>
> Yeah I am also thinking that it is probably too late to make changes in 
CBGVs. But one this we certainly do is add request in args tuple in 
dispatch method. This way backward compatibility can be ensured pretty 
easily. 

Currently many decorators have been written keeping these signatures in 
mind. Changing the whole signature will definitely break many of third 
party applications. I didn't get much time to try changing this signature, 
but I am pretty much certain about the destruction it will cause!
 

> On 23 October 2015 at 14:45, Tom Christie <christ...@gmail.com 
> > wrote:
>
>> Although those variables are available in both places I'd prefer to see 
>> them passed explicitly.
>> That will tend to nudge users slightly more towards passing variable 
>> around explicitly and slightly away from storing state on the view instance 
>> (which can be a bit of a gnarly practice - harder to follow the flow of 
>> where and when some piece of information is actually being used/modified)
>>
>> On Friday, 23 October 2015 14:03:17 UTC+1, Tim Graham wrote:
>>>
>>> It looks like setting the request/args/kwargs attributes came after the 
>>> original CBGV implementation. 
>>>
>>> https://github.com/django/django/commit/ea6b95db
>>> https://code.djangoproject.com/ticket/19316
>>>
>>> https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion
>>>
>>> I haven't looked closely to see if your proposal might cause problems 
>>> (you could give it a try and see if you can get the Django test suite 
>>> passing), however, changing the signature of those methods would require a 
>>> deprecation path and could result in a lot of churn in user code which 
>>> would probably cause some angst. I'll leave it to users of CGGVs to offer 
>>> an opinion on whether or not it could be worthwhile.
>>>
>>> On Friday, October 23, 2015 at 5:51:37 AM UTC-4, Dheerendra Rathor wrote:
>>>>
>>>> Hello all,
>>>>
>>>> With reference to this line: 
>>>> https://github.com/django/django/blob/master/django/views/generic/base.py#L61
>>>>  
>>>> from django.view.generic.base
>>>> before calling self.dispatch request, args and kwargs attributes have 
>>>> been added to self. So these all are available in self in http_method 
>>>> handlers. 
>>>>
>>>> I think this behaviour is present due to old functional views, but now 
>>>> passing these as arguments to http_method handlers look obsolete.
>>>>
>>>> We can potentially remove these and make http handlers more simple just 
>>>> like
>>>> class CustomView(View):
>>>> def get(self):
>>>> request =self.request
>>>> # code ...
>>>>
>>>>
>>>>
>>>> -- 
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/6fe6b37d-8ab6-4c66-b036-db480547c4fd%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/6fe6b37d-8ab6-4c66-b036-db480547c4fd%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
On Friday, 23 October 2015 19:31:07 UTC+5:30, Marc Tamlyn wrote:
>
> This would cause too much churn for user code - there are millions of CBVs 
> in the wild with customised dispatch/get/post/etc methods which expect 
> these variables and perhaps use them directly. Unfortunately this ship has 
> sailed.
>
> On 23 October 2015 at 14:45, Tom Christie <christ...@gmail.com 
> > wrote:
>
>> Although those variables are available in both places I'd prefer to see 
>> them passed explicitly.
>> That will tend to nudge users slightly more towards passing var

Re: #25582: Add a way to build URLs with query strings

[Dheerendra Rathor]

How about a wrapper over reverse? 
Modifying reverse will lead to multiple changes in core urlresolver. 

A class based urlresolver can be implemented which will call reverse 
internally. 


On Friday, 23 October 2015 17:29:25 UTC+5:30, guettli wrote:
>
> API proposal:
>
> Add a new kwarg to reverse():
>
>reverse(..., get=None)
>
>
> Example: reverse('my_view_name', kwargs={'pk': '1'}, get=dict(param='value')
>
> result: /my-view/1?param=value
>
>
>
>
> Am Freitag, 23. Oktober 2015 13:43:18 UTC+2 schrieb Tim Graham:
>>
>> Can you make an API proposal?
>>
>> On Friday, October 23, 2015 at 3:41:42 AM UTC-4, guettli wrote:
>>>
>>> From  https://code.djangoproject.com/ticket/25582
>>>
>>>  {{{
>>>
>>> It is a common question on stackoverflow and other places:
>>>
>>> How to reverse() to url including GET parameters? Example: 
>>> .../myview?foo=bar
>>>
>>> ​
>>> http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse
>>>
>>> ​http://stackoverflow.com/a/27641445/633961
>>>
>>> It would be very nice if django could implement a short-cut which 
>>> provides
>>> this.
>>> It would be useful for python code and template, too.
>>> }}}
>>>
>>> {{{
>>> If we do add it, it likely needs a discussion on the 
>>> DevelopersMailingList 
>>>  to figure 
>>> out what the API should look like. See also #10941 
>>>  which asks for a template 
>>> tag for creating query strings in templates.
>>> }}}
>>>
>>> What do you think?
>>>
>>>
>>>
>>>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b7b53d11-eb6d-46e4-8a98-2a7c5f2fd991%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Why passing request, *args, **kwargs in dispatch method for generic views

[Dheerendra Rathor]

Hello all,

With reference to this 
line: 
https://github.com/django/django/blob/master/django/views/generic/base.py#L61 
from django.view.generic.base
before calling self.dispatch request, args and kwargs attributes have been 
added to self. So these all are available in self in http_method handlers. 

I think this behaviour is present due to old functional views, but now 
passing these as arguments to http_method handlers look obsolete.

We can potentially remove these and make http handlers more simple just like
class CustomView(View):
def get(self):
request =self.request
# code ...



-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8f7ece4f-e2c5-45a5-b35d-f4fd4e7d58f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.