Re: Sonar for the Django rpoject

[Hanne Moa]

Is there a way to ignore django.utils.dateformat? That code is very
straight forward, and it is not supposed to be called manually by humans. I
can't see how a "fix" would improve things. Munging the second string in
the getattr? Adding "upper" and "lower" or something similar to each
method-name?

On 31 August 2016 at 19:50, Ivan Sevastoyanov 
wrote:

>
> 
> I'm posting the the 11 criticals. In my opinion, they are not critical,
> they are just code smells. I will try to export the report so you can
> review the major issues by groups.
>
> Regards,
> Ivan
>
>

-- 
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/CACQ%3DrrfUwi5QQNqrDYB59fi47RjQ5gUYoHjZwiTuGDXBbnakEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django default PK type setting

[Marc Tamlyn]

For what it's worth I think this is *much* harder than it appears on the
surface. Whilst setting another field as the PK is easy, setting another
base type as an "auto" field is surprisingly tricky - lots of AutoField
assumes integers.

However, I do think it has some merits. An obvious benefit to the
consistency is when you are using another framework with Django which makes
certain assumptions about the way you identify objects. Some front end
frameworks prefer guids to integers, as would some security protocols.

M

On 1 Sep 2016 5:49 p.m., "Emett Speer"  wrote:

> I agree with you in recommending against using `.filter(pk=1)` in testing.
>
> What do you think of the idea though. Do you think it would be worth
> looking into adding a flag for new projects or not worth the time/effort to
> add it.
>
> On Wednesday, August 31, 2016 at 10:11:55 PM UTC-7, Shai Berger wrote:
>>
>> On Thursday 01 September 2016 02:51:54 Josh Smeaton wrote:
>> > A major issue with this would be the many apps out in the wild (and
>> their
>> > tests!) that assume the pk is an integer, and do queries like
>> > .filter(pk=1).
>>
>> FWIW, this is a bad practice which we should recommend against. In
>> databases
>> which rely on sequences, after you've run some tests, the pk of the first
>> record in a table is not necessarily 1 (because records in the table are
>> removed when test transactions are rolled back, but sequence values are
>> not
>> re-used). Similar issues can arise in parallel execution of tests.
>>
>> [This is a bit off-topic for the pk-type setting idea, I know]
>>
>> Shai.
>>
> --
> 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/4422aad9-a9aa-4076-b24a-
> 659c0594e4f9%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/CAMwjO1F9_ftSGLnaGQPp73CLrn6L167qVZMeTOOuasiTEWZSkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PEP 484 type hinting in Django

[Daniel Moisset]

Hi Graham, thanks for the support.

I'm aiming at Django 1.10 right now, but given that APIs are more stable
than implementation, you may have some success with other versions. This is
just a guess, I haven't tried

Best,
D.

On Sat, Aug 27, 2016 at 7:29 AM, Graham Wideman 
wrote:

> First -- three thumbs up for Daniel's initiative and advocacy!  Count me
> in as a random enthusiastic would-be user.
>
> Question: I've looked at Daniels repo and the pyi files therein, and one
> issue is ascertaining which version of Django they apply to. Are there some
> ideas about how that's to be done?
>
> Graham
>
> On Wednesday, August 17, 2016 at 7:13:51 AM UTC-7, dmoisset wrote:
>>
>> Thanks for the replies,
>>
>> As I mentioned, I have already started implementation ...
>>
> --
> 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/ac0102f7-9106-40dd-be62-
> 17fcb30c0f1f%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Daniel F. Moisset - UK Country Manager
www.machinalis.com
Skype: @dmoisset

-- 
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/CALuYSZWGUip3PenKNBMWSOJbmTkijMBWWM0qo1YeO3GR7RWF9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.10 release blockers

[Tim Graham]

As usual, the monthly bug fix release (1.10.1) is planned for tomorrow, 
September 1.

A remaining issue that could use some attention is about makemigrations and 
the new history consistency checks that were added in 1.10. These checks 
created problems in various multiple database setups, for example, with a 
read-only database. I've implemented a proposal to consult database 
routers, however, there remains a possibility for backwards-incompatibility 
as described in https://code.djangoproject.com/ticket/27142#comment:11. I'm 
okay with deferring the issue until next month if we can't come to a 
consensus. In particular, none of the ticket reporters have commented about 
whether or not the fix solves their issue.

PR: https://github.com/django/django/pull/7194 

On Saturday, July 30, 2016 at 9:20:46 PM UTC-4, Tim Graham wrote:
>
> The final release is on schedule for Monday, August 1.
>
> On Thursday, July 14, 2016 at 10:05:39 AM UTC-4, Markus Holtermann wrote:
>>
>> Thank you for the update, Tim. 
>>
>> #26888 will be taken care of by tomorrow. Either Marten or I are pushing 
>> a PR. 
>>
>> Cheers, 
>>
>> /Markus 
>>
>> On Thu, Jul 14, 2016 at 06:41:51AM -0700, Tim Graham wrote: 
>> >I'm planning for the release candidate on Monday. 
>> > 
>> >The one blocker is #26888  
>> - 
>> >RegexURLResolver doesn't work in threaded environments. 
>> > 
>> >On Tuesday, June 21, 2016 at 4:29:47 PM UTC-4, Tim Graham wrote: 
>> >> 
>> >> The blocker is merged so I'll release the beta in a couple hours if no 
>> one 
>> >> stops me. 
>> >> 
>> >> On Monday, June 20, 2016 at 9:10:12 PM UTC-4, Tim Graham wrote: 
>> >>> 
>> >>> The remaining blocker: 
>> >>> 
>> >>> UserCreationForm doesn't call normalize_email and normalize_username 
>> >>> https://code.djangoproject.com/ticket/26719 
>> >>> Status: I sent some final edits to the PR and it should be ready for 
>> >>> commit tomorrow. 
>> >>> 
>> >>> Other possible blockers: 
>> >>> 
>> >>> Different manager for _base_manager and related descriptors 
>> >>> https://code.djangoproject.com/ticket/26749 
>> >>> django-hvad is broken by the manager inheritance refactor and it's 
>> >>> unclear if it can be adapted for the new behavior. 
>> >>> 
>> >>> Update decorator_from_middleware() to work with DEP5 style 
>> middleware. 
>> >>> https://code.djangoproject.com/ticket/26626 
>> >>> Design decision needed, see 
>> >>> 
>> https://groups.google.com/d/topic/django-developers/hNQIaYcN3xM/discussion 
>> >>> 
>> >>> As long as no new issues pop up by tomorrow, I'm thinking to do the 
>> beta 
>> >>> release then. We might consider a "beta 2" release around 2 weeks 
>> later if 
>> >>> we decide to push fixes for the other two issues. 
>> >>> 
>> >>> On Saturday, June 18, 2016 at 8:05:32 PM UTC-4, Tim Graham wrote: 
>>  
>>  I'm postponing the release until next week as some release blockers 
>>  remain: 
>>  
>>  
>>  
>> https://code.djangoproject.com/query?status=!closed&severity=Release%20blocker
>>  
>>  
>>  On Friday, June 17, 2016 at 5:33:04 PM UTC-4, Claude Paroz wrote: 
>> > 
>> > Le vendredi 17 juin 2016 16:52:50 UTC+2, Tim Graham a écrit : 
>> >> 
>> >> There are a few small issues to finish up, but if all goes well, 
>> the 
>> >> beta release will happen sometime tomorrow (at least 24 hours from 
>> now). 
>> >> 
>> > 
>> > I'm a bit worried about https://code.djangoproject.com/ticket/26719 
>> > which could have security implications for 1.10. To be 
>> investigated... 
>> > 
>> > Claude 
>> > 
>>  
>> > 
>> >-- 
>> >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/94dd42e9-6940-4377-bd8e-7b285d0a63bc%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/504c5be0-9cc5-4af7-8b0d-1d254ab388aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sonar for the Django rpoject

[Aymeric Augustin]

Hello Ivan,

Given that both Django and Sonar are open-source, anyone should be able to 
reproduce your results easily… If there are security issues, please email them 
to secur...@djangoproject.com  instead of 
publishing them. That’ll make them a bit less easy to discover. Otherwise, go 
ahead and post the issues wherever is most convenient for you.

Thanks,

-- 
Aymeric.

> On 31 Aug 2016, at 08:25, Ivan Sevastoyanov  
> wrote:
> 
> All the rules are with a default severity so there might be some major issues 
> that it's worth reviewing them. I will post the critical issues this evening 
> because I'm at work now. Do you want to post them somewhere else because it's 
> a sensitive information? I will try to find out how to export the whole 
> report in a convenient format.
> 
> Regards,
> Ivan
> 
> On Wednesday, August 31, 2016 at 12:55:35 AM UTC+3, Tim Graham wrote:
> Perhaps you could tell us about some of the critical issues so we could get a 
> sense for that.
> 
> On Tuesday, August 30, 2016 at 4:26:42 PM UTC-4, Ivan Sevastoyanov wrote:
>  
> That
>  is the report from the Sonar with all the rules included. Unfortunately, I 
> cannot export it as a PDF or some more convenient format. I can describe all 
> the steps in my blog so some of the Django members could set up Sonar on 
> his/her machine and see a lot more details and figure out if it's worth it to 
> fix some of the issues.
> 
> On Sunday, August 28, 2016 at 11:16:57 PM UTC+3, Aymeric Augustin wrote:
> On 28 Aug 2016, at 21:43, Ivan Sevastoyanov > wrote: 
> 
> > My question is do you consider using SonarQube for code quality analysis, 
> > static analysis and find bugs because it's able to do that. 
> 
> 
> I guess that depends on the signal / noise ratio in the things SonarQube 
> flags. 
> 
> Perhaps you could do an initial run and see whether SonarQube spots 
> interesting bugs? 
> 
> I have no idea what the results could be because I’m not familiar with static 
> analysis of Python code. 
> 
> -- 
> Aymeric. 
> 
> 
> -- 
> 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/f7d07e45-c0a4-4285-9ce8-3605c9885d4e%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/B1865E8C-1539-4937-B833-BF9F5A3D60B0%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Helping a Newbie

[Dávid Főző]

Dear Devs,

I would like to contribute to the Django code base as a python developer. I 
am a user of Django, but haven't delved on into the code itself that 
thoroughly. After I read through the documentation a couple times, it's 
still not clear how do you select the ticket. I mean how do you know you 
are good enough for the job. I am a little shy about claiming any ticket, 
because I have no idea about the functions and methods described on those 
tickets. Just reading through the titles seems overwhelming.

If somebody could do and easy pick with me, I would really really grateful!

-- 
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/bc4a6d7a-320e-4fbe-aaf2-2b30c7641a42%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.10 release blockers

[Tim Graham]

As usual, the monthly bug fix release (1.10.1) is planned for tomorrow, 
September 1.

There's one issue that could use some attention. The new migrations history 
consistency checks in makemigrations have triggered some problems in 
various multiple database setups, such as with a read-only non-default 
database. I implemented a proposal to consult database routers to decide 
whether or not to do the checks, however, there remains some possibility of 
backwards-incompatibility as described in 
https://code.djangoproject.com/ticket/27142#comment:11. I don't mind 
deferring the issue until next month if there isn't a consensus. In 
particular, there's been no feedback from the ticket reporters on whether 
or not the PR works for them.

PR: https://github.com/django/django/pull/7194

On Saturday, July 30, 2016 at 9:20:46 PM UTC-4, Tim Graham wrote:
>
> The final release is on schedule for Monday, August 1.
>
> On Thursday, July 14, 2016 at 10:05:39 AM UTC-4, Markus Holtermann wrote:
>>
>> Thank you for the update, Tim. 
>>
>> #26888 will be taken care of by tomorrow. Either Marten or I are pushing 
>> a PR. 
>>
>> Cheers, 
>>
>> /Markus 
>>
>> On Thu, Jul 14, 2016 at 06:41:51AM -0700, Tim Graham wrote: 
>> >I'm planning for the release candidate on Monday. 
>> > 
>> >The one blocker is #26888  
>> - 
>> >RegexURLResolver doesn't work in threaded environments. 
>> > 
>> >On Tuesday, June 21, 2016 at 4:29:47 PM UTC-4, Tim Graham wrote: 
>> >> 
>> >> The blocker is merged so I'll release the beta in a couple hours if no 
>> one 
>> >> stops me. 
>> >> 
>> >> On Monday, June 20, 2016 at 9:10:12 PM UTC-4, Tim Graham wrote: 
>> >>> 
>> >>> The remaining blocker: 
>> >>> 
>> >>> UserCreationForm doesn't call normalize_email and normalize_username 
>> >>> https://code.djangoproject.com/ticket/26719 
>> >>> Status: I sent some final edits to the PR and it should be ready for 
>> >>> commit tomorrow. 
>> >>> 
>> >>> Other possible blockers: 
>> >>> 
>> >>> Different manager for _base_manager and related descriptors 
>> >>> https://code.djangoproject.com/ticket/26749 
>> >>> django-hvad is broken by the manager inheritance refactor and it's 
>> >>> unclear if it can be adapted for the new behavior. 
>> >>> 
>> >>> Update decorator_from_middleware() to work with DEP5 style 
>> middleware. 
>> >>> https://code.djangoproject.com/ticket/26626 
>> >>> Design decision needed, see 
>> >>> 
>> https://groups.google.com/d/topic/django-developers/hNQIaYcN3xM/discussion 
>> >>> 
>> >>> As long as no new issues pop up by tomorrow, I'm thinking to do the 
>> beta 
>> >>> release then. We might consider a "beta 2" release around 2 weeks 
>> later if 
>> >>> we decide to push fixes for the other two issues. 
>> >>> 
>> >>> On Saturday, June 18, 2016 at 8:05:32 PM UTC-4, Tim Graham wrote: 
>>  
>>  I'm postponing the release until next week as some release blockers 
>>  remain: 
>>  
>>  
>>  
>> https://code.djangoproject.com/query?status=!closed&severity=Release%20blocker
>>  
>>  
>>  On Friday, June 17, 2016 at 5:33:04 PM UTC-4, Claude Paroz wrote: 
>> > 
>> > Le vendredi 17 juin 2016 16:52:50 UTC+2, Tim Graham a écrit : 
>> >> 
>> >> There are a few small issues to finish up, but if all goes well, 
>> the 
>> >> beta release will happen sometime tomorrow (at least 24 hours from 
>> now). 
>> >> 
>> > 
>> > I'm a bit worried about https://code.djangoproject.com/ticket/26719 
>> > which could have security implications for 1.10. To be 
>> investigated... 
>> > 
>> > Claude 
>> > 
>>  
>> > 
>> >-- 
>> >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/94dd42e9-6940-4377-bd8e-7b285d0a63bc%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/45820b89-1f2c-445a-95ba-b05744b18b5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add past/present/future validations for Date and DateTime types

[Aymeric Augustin]

I suppose Min / MaxValueValidator cannot be reused here because they expect a 
fixed bound, while past / future depends on the current date?

The implementation Mariano provided looks simple enough to reproduce and adapt 
to each project’s requirements (even though I’d prefer duck typing to type 
checks). Note that it assumes that USE_TZ = False while Django sets USE_TZ = 
True by default.

-- 
Aymeric.

> On 31 Aug 2016, at 03:04, Tim Graham  wrote:
> 
> Thanks for the proposal. MaxValueValidator and MaxValueValidator are included 
> because they're needed for IntegerField validation. I don't think the 
> proposed validators meet the criteria of "needed in 80% of Django projects" 
> or "can't easily be implemented as a third-party app".
> 
> On Tuesday, August 30, 2016 at 4:20:36 PM UTC-4, Mariano Baragiola wrote:
> Hello django-developers@, 
> 
> On more than one project, I find myself implementing the same feature over
> and over again. It's not a rare case scenario, for instance: it's common
> that invoices have a date that belongs to the past or the present time, but
> not the future.
> 
> Seeing that we have django.core.validators.MinValueValidator and
> django.core.validators.MaxValueValidator, I propose the following:
> 
> * django.core.validators.DateIsPresent
> * django.core.validators.DateIsPresentOrPast
> * django.core.validators.DateIsPresentOrFuture
> * django.core.validators.DateIsFuture
> 
> This way, one may easily use them at models.py just like MinValueValidator
> and MaxValueValidator.
> 
> The code would be really simple, I have them -differently- implemented at:
> https://github.com/heimdalerp/heimdalerp/blob/master/common/validators.py 
> 
> 
> Please, let me know if there's already an easier way to do this with
> current Django, or if this belongs to a custom app instead.
> 
> If it is ok to add this feature to Django, I can gladly take care of it.
> 
> Thanks in advance. 
> 
> -- 
> 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/62bd473f-19bb-4140-b04f-ba733e8b78e5%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/8421D044-5BD2-4375-A3B6-CA0E0077638F%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Sonar for the Django rpoject

[Alex Gaynor]

If these are what qualifies as critical, I don't think this is a good use
of our time.

Alex

On Wed, Aug 31, 2016 at 1:50 PM, Ivan Sevastoyanov <
ivan.sevastoya...@gmail.com> wrote:

>
> 
> I'm posting the the 11 criticals. In my opinion, they are not critical,
> they are just code smells. I will try to export the report so you can
> review the major issues by groups.
>
> Regards,
> Ivan
>
> On Wednesday, August 31, 2016 at 2:15:48 PM UTC+3, Tim Graham wrote:
>>
>> Any security issues should be reported to secu...@djangoproject.com,
>> otherwise it's fine to share the information here.
>>
>> On Wednesday, August 31, 2016 at 2:25:55 AM UTC-4, Ivan Sevastoyanov
>> wrote:
>>>
>>> All the rules are with a default severity so there might be some major
>>> issues that it's worth reviewing them. I will post the critical issues this
>>> evening because I'm at work now. Do you want to post them somewhere else
>>> because it's a sensitive information? I will try to find out how to export
>>> the whole report in a convenient format.
>>>
>>> Regards,
>>> Ivan
>>>
>>> On Wednesday, August 31, 2016 at 12:55:35 AM UTC+3, Tim Graham wrote:

 Perhaps you could tell us about some of the critical issues so we could
 get a sense for that.

 On Tuesday, August 30, 2016 at 4:26:42 PM UTC-4, Ivan Sevastoyanov
 wrote:
>
>
> 
> That is the report from the Sonar with all the rules included.
> Unfortunately, I cannot export it as a PDF or some more convenient format.
> I can describe all the steps in my blog so some of the Django members 
> could
> set up Sonar on his/her machine and see a lot more details and figure out
> if it's worth it to fix some of the issues.
>
> On Sunday, August 28, 2016 at 11:16:57 PM UTC+3, Aymeric Augustin
> wrote:
>>
>> On 28 Aug 2016, at 21:43, Ivan Sevastoyanov 
>> wrote:
>>
>> > My question is do you consider using SonarQube for code quality
>> analysis, static analysis and find bugs because it's able to do that.
>>
>>
>> I guess that depends on the signal / noise ratio in the things
>> SonarQube flags.
>>
>> Perhaps you could do an initial run and see whether SonarQube spots
>> interesting bugs?
>>
>> I have no idea what the results could be because I’m not familiar
>> with static analysis of Python code.
>>
>> --
>> Aymeric.
>>
>> --
> 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/7263b3cc-a0b6-4dc6-9a33-
> 204ed3aac9a5%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
"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
GPG Key fingerprint: D1B3 ADC0 E023 8CA6

-- 
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/CAFRnB2VTa2vEKswH357Lk%3D3KmcRSacj0W4UwCvNrDreq2SgqWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django default PK type setting

[Aymeric Augustin]

I tend to agree with Marc.

While I’m less than enthusiastic about the prospect of adding a new setting for 
this, I noticed a few times in the past that Django's support for UUID PKs was 
buggy, perhaps in the admin (I don’t remember the details and I can’t say if 
all these bugs have been fixed).

First-class support for UUID PKs — which are strings, that’s the interesting 
property here — may require removing various shortcuts that assume integer PKs 
and that would be a good thing.

This is neither very concrete nor very helpful, sorry…

-- 
Aymeric.

> On 01 Sep 2016, at 19:10, Marc Tamlyn  wrote:
> 
> For what it's worth I think this is *much* harder than it appears on the 
> surface. Whilst setting another field as the PK is easy, setting another base 
> type as an "auto" field is surprisingly tricky - lots of AutoField assumes 
> integers.
> 
> However, I do think it has some merits. An obvious benefit to the consistency 
> is when you are using another framework with Django which makes certain 
> assumptions about the way you identify objects. Some front end frameworks 
> prefer guids to integers, as would some security protocols.
> 
> M
> 
> 
> On 1 Sep 2016 5:49 p.m., "Emett Speer"  > wrote:
> I agree with you in recommending against using `.filter(pk=1)` in testing.
> 
> What do you think of the idea though. Do you think it would be worth looking 
> into adding a flag for new projects or not worth the time/effort to add it.
> 
> On Wednesday, August 31, 2016 at 10:11:55 PM UTC-7, Shai Berger wrote:
> On Thursday 01 September 2016 02:51:54 Josh Smeaton wrote: 
> > A major issue with this would be the many apps out in the wild (and their 
> > tests!) that assume the pk is an integer, and do queries like 
> > .filter(pk=1). 
> 
> FWIW, this is a bad practice which we should recommend against. In databases 
> which rely on sequences, after you've run some tests, the pk of the first 
> record in a table is not necessarily 1 (because records in the table are 
> removed when test transactions are rolled back, but sequence values are not 
> re-used). Similar issues can arise in parallel execution of tests. 
> 
> [This is a bit off-topic for the pk-type setting idea, I know] 
> 
> Shai. 
> 
> -- 
> 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/4422aad9-a9aa-4076-b24a-659c0594e4f9%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/CAMwjO1F9_ftSGLnaGQPp73CLrn6L167qVZMeTOOuasiTEWZSkg%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6E221E4A-B7A3-403C-9E73-8930559B30E2%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Sonar for the Django rpoject

[James Bennett]

On Wed, Aug 31, 2016 at 10:55 AM, Alex Gaynor  wrote:

> If these are what qualifies as critical, I don't think this is a good use
> of our time.
>
>
>
Agreed. If those are the critical things, then either Django is really
really good, or there are things it's missing. I suspect there are things
it's missing.

-- 
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/CAL13Cg-37%2B46uF_Vkp%2BGhUoJ5vZcKkMM%2BeQLibT28z4s5dDJmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django default PK type setting

[Emett Speer]

I have not run into any issues with UUID PKs with Django 1.8 - 1.10 yet. If 
memory services me the UUIDFIeld in models is still relatively new at the 
moment.

On Monday, September 5, 2016 at 7:12:35 AM UTC-7, Aymeric Augustin wrote:
>
> I tend to agree with Marc.
>
> While I’m less than enthusiastic about the prospect of adding a new 
> setting for this, I noticed a few times in the past that Django's support 
> for UUID PKs was buggy, perhaps in the admin (I don’t remember the details 
> and I can’t say if all these bugs have been fixed).
>
> First-class support for UUID PKs — which are strings, that’s the 
> interesting property here — may require removing various shortcuts that 
> assume integer PKs and that would be a good thing.
>
> This is neither very concrete nor very helpful, sorry…
>
> -- 
> Aymeric.
>
> On 01 Sep 2016, at 19:10, Marc Tamlyn > 
> wrote:
>
> For what it's worth I think this is *much* harder than it appears on the 
> surface. Whilst setting another field as the PK is easy, setting another 
> base type as an "auto" field is surprisingly tricky - lots of AutoField 
> assumes integers.
>
> However, I do think it has some merits. An obvious benefit to the 
> consistency is when you are using another framework with Django which makes 
> certain assumptions about the way you identify objects. Some front end 
> frameworks prefer guids to integers, as would some security protocols.
>
> M
>
> On 1 Sep 2016 5:49 p.m., "Emett Speer" > 
> wrote:
>
>> I agree with you in recommending against using `.filter(pk=1)` in testing.
>>
>> What do you think of the idea though. Do you think it would be worth 
>> looking into adding a flag for new projects or not worth the time/effort to 
>> add it.
>>
>> On Wednesday, August 31, 2016 at 10:11:55 PM UTC-7, Shai Berger wrote:
>>>
>>> On Thursday 01 September 2016 02:51:54 Josh Smeaton wrote: 
>>> > A major issue with this would be the many apps out in the wild (and 
>>> their 
>>> > tests!) that assume the pk is an integer, and do queries like 
>>> > .filter(pk=1). 
>>>
>>> FWIW, this is a bad practice which we should recommend against. In 
>>> databases 
>>> which rely on sequences, after you've run some tests, the pk of the 
>>> first 
>>> record in a table is not necessarily 1 (because records in the table are 
>>> removed when test transactions are rolled back, but sequence values are 
>>> not 
>>> re-used). Similar issues can arise in parallel execution of tests. 
>>>
>>> [This is a bit off-topic for the pk-type setting idea, I know] 
>>>
>>> Shai. 
>>>
>>
>> -- 
>> 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/4422aad9-a9aa-4076-b24a-659c0594e4f9%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-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/CAMwjO1F9_ftSGLnaGQPp73CLrn6L167qVZMeTOOuasiTEWZSkg%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d50f8b9b-e19a-4b8a-9a8b-2464a6b278e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django default PK type setting

[Emett Speer]

I'm happy to hear that I'm not 100% alone on this one.

I also agree that this would be a much harder add then it may appear. 
Though I'm not suggesting any modifications to the AutoField I'm suggesting 
a setting that would make undefined ID fields in models UUID's by default 
rather then an Int. This would also need to change the current Django 
models from Int to UUID. I think it maybe best to have it as a flag when 
you start your project as the migration from Int to UUID can be rather 
painful.

On Monday, September 5, 2016 at 6:08:30 AM UTC-7, Marc Tamlyn wrote:
>
> For what it's worth I think this is *much* harder than it appears on the 
> surface. Whilst setting another field as the PK is easy, setting another 
> base type as an "auto" field is surprisingly tricky - lots of AutoField 
> assumes integers.
>
> However, I do think it has some merits. An obvious benefit to the 
> consistency is when you are using another framework with Django which makes 
> certain assumptions about the way you identify objects. Some front end 
> frameworks prefer guids to integers, as would some security protocols.
>
> M
>
> On 1 Sep 2016 5:49 p.m., "Emett Speer" > 
> wrote:
>
>> I agree with you in recommending against using `.filter(pk=1)` in testing.
>>
>> What do you think of the idea though. Do you think it would be worth 
>> looking into adding a flag for new projects or not worth the time/effort to 
>> add it.
>>
>> On Wednesday, August 31, 2016 at 10:11:55 PM UTC-7, Shai Berger wrote:
>>>
>>> On Thursday 01 September 2016 02:51:54 Josh Smeaton wrote: 
>>> > A major issue with this would be the many apps out in the wild (and 
>>> their 
>>> > tests!) that assume the pk is an integer, and do queries like 
>>> > .filter(pk=1). 
>>>
>>> FWIW, this is a bad practice which we should recommend against. In 
>>> databases 
>>> which rely on sequences, after you've run some tests, the pk of the 
>>> first 
>>> record in a table is not necessarily 1 (because records in the table are 
>>> removed when test transactions are rolled back, but sequence values are 
>>> not 
>>> re-used). Similar issues can arise in parallel execution of tests. 
>>>
>>> [This is a bit off-topic for the pk-type setting idea, I know] 
>>>
>>> Shai. 
>>>
>> -- 
>> 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/4422aad9-a9aa-4076-b24a-659c0594e4f9%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/a0fae15f-3125-4e59-90bd-d544f77d80d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PEP 484 type hinting in Django

[Graham Wideman]

Hi Daniel, thanks for replying.  

My question was less about what version of django you were targeting, and 
more about how a type-hints library such as this should be annotated to 
indicate what version(s) it targets. Since a type hints library may well be 
distributed separately from the code that it hints, it won't necessarily be 
obvious.

Graham

On Monday, September 5, 2016 at 6:08:30 AM UTC-7, dmoisset wrote:
>
> Hi Graham, thanks for the support.
>
> I'm aiming at Django 1.10 right now, but given that APIs are more stable 
> than implementation, you may have some success with other versions. This is 
> just a guess, I haven't tried
>
> Best,
> D.
>
> On Sat, Aug 27, 2016 at 7:29 AM, Graham Wideman  > wrote:
>
>> First -- three thumbs up for Daniel's initiative and advocacy!  Count me 
>> in as a random enthusiastic would-be user.
>>
>> Question: I've looked at Daniels repo and the pyi files therein, and one 
>> issue is ascertaining which version of Django they apply to. Are there some 
>> ideas about how that's to be done?
>>
>> Graham
>>
>> On Wednesday, August 17, 2016 at 7:13:51 AM UTC-7, dmoisset wrote:
>>>
>>> Thanks for the replies,
>>>
>>> As I mentioned, I have already started implementation ...
>>>
>> -- 
>> 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/ac0102f7-9106-40dd-be62-17fcb30c0f1f%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Daniel F. Moisset - UK Country Manager
> www.machinalis.com
> Skype: @dmoisset
>

-- 
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/742428b5-7ab3-4d0b-bed3-30775620b3aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.