Take index type into account in inspectdb command

[akki]

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/28795bda-263b-4d6b-9c04-b5790adba868%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: should blank POST data fallback to use model field defaults?

[Tim Graham]

I completed the pull request to restore the fallback for empty data, except 
for CheckboxInput. If you have any input, please speak up. 
https://github.com/django/django/pull/7068

On Wednesday, August 17, 2016 at 7:40:56 AM UTC-4, Tim Graham wrote:
>
> I think there's a misunderstanding. As the documentation says, 
> forms.BooleanField(required=False) is the common case because required=True 
> means the checkbox must be checked. It's only confusing in the context of a 
> non-browser request where empty POST data might have a different meaning.
>
> https://docs.djangoproject.com/en/stable/ref/forms/fields/#booleanfield
>
> On Wednesday, August 17, 2016 at 7:04:35 AM UTC-4, Michael Foster wrote:
>>
>> I believe Tom is right. The documentation is trivial but there is a need 
>> to raise an error or warning to the user when specifying required=False for 
>> boolean fields, as it is nonsensical.
>>
>> On Tuesday, August 16, 2016 at 12:52:06 AM UTC+1, Tom Christie wrote:
>>>
>>> It's not perfect but given that it's an inherent limitation of HTML 
>>> checkboxes, I don't think that documenting that limitation is that big a 
>>> deal.
>>>
>>> forms.BooleanField(required=False) feels like an odd combination to me 
>>> in any case. One way we could potentially help users would be to error in 
>>> that case unless an alternate widget is used (We could recommend select or 
>>> whatever it is we use for NullBooleanField in this case)
>>>
>>> We have the same issue in REST framework serializers FWIW. As with 
>>> Django<1.10 we treat omission as omission, not blank. And yes, we have to 
>>> special-case boolean omission.
>>>
>>>

-- 
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/ecfac262-4320-4c45-9d94-04fb17be242e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PEP 484 type hinting in Django

[ludovic coues]

Dropping support for python 2.7 has been planned for some time. Django
1.11 will be the last one supporting python 2. The following release
will be django 2 and will only support django 3.5+. See
https://docs.djangoproject.com/en/dev/releases/1.11/

That's what Tim was talking about. You can target inclusion in django
2 and forget about the quite uglier #type comment.

2016-08-17 16:13 GMT+02:00 Daniel Moisset :
> Thanks for the replies,
>
> As I mentioned, I have already started implementation (and I'm willing to go
> through with it, having even some time from my work allocated to do it); I
> wasn't aware of the JetBrains plan (it's a nice plus, but I don't depend on
> it), and I'll probably do it as external files if the django core team
> itself is not interested, but I think it's more beneficial to do it inline.
>
> One clarification is that there is no need to drop 2.7 support to use inline
> annotations; there's a python2 compatible way to annotate described now in
> PEP484.
>
> What I'd like to do is to get a reading of the room to see if there's some
> degree of interest (at least a "I'm curious to see how it looks if you do
> the work") before following up with the DEP process. I made a very quick
> summary of what I think the benefits would be, but if it's not clear I'd be
> happy to ellaborate.
>
> Some key things that have changed since last year (regarding the links
> posted by Florian and Tim) are:
>
> * PEP-484 is now approved and standard part of python. The mypy checker is
> now under the python project umbrella and getting active maintainance and
> backed by key people in the python community
> * Having a standard (instead of just a 3rd party tool supporting this) means
> that this now annotations can help to interoperate with many tools (type
> checkers, editors, documentation generators, refactoring tools), so the
> impact in the ecosystem is larger
> * There's some evidence that this works on production (people in dropbox
> have been using it for ~ a year, according to [1])
> * There are several complaints telling that "this won't be actually
> optional", but I see no evidence to support it. And in any case those are
> arguments around deciding to include this in the language, and that decision
> has been made already. But in my experience, annotations help more in some
> particular modules/APIs and not in others, so an abvious option is to add
> them only where they add value (i.e. increase readbility and clarity of
> interfaces)
> * Cory Benfield points at some complex types, that (from a quick look) with
> new type aliases and overload semantics can probably be described in a much
> simpler and readable way. And again, if they don't that function (or that
> argument) shouldn't be annotated.
> * There's someone volunteering to do the work (me and some colleagues at
> Machinalis) :)
>
> I've already been looking at some interfaces in django and I feel that a lot
> of them are as not dynamic and polymorphic as requests is, so some success
> can be achieved here.
>
> So, how do you guys feel about this? what are the risks/fears that you'd
> like to have addressed? do you share my opinion that this will be positive
> for both the framework and its users?
>
> Best,
>
> [1] http://pythonpodcast.com/david-greg-mypy.html
>
>
> On Wed, Aug 17, 2016 at 2:41 PM, Tim Graham  wrote:
>>
>> The JetBrains announcement that they want to fund the project isn't a
>> guarantee that it'll be implemented. The feature needs to go through the
>> normal feature acceptance process, which as Markus said, might involve a
>> DEP.
>>
>> Assuming the idea is accepted, my sense on timing would be to wait until
>> January when Django drops support for Python 2.7 and 3.4 in master. Then we
>> could use inline annotations rather than the stub files.
>>
>> Past discussions of type hinting:
>> https://groups.google.com/d/topic/django-developers/z_P1TvJ6QG8/discussion
>> https://groups.google.com/d/topic/django-developers/xOTmq93YZuQ/discussion
>>
>> On Wednesday, August 17, 2016 at 5:30:56 AM UTC-4, Florian Apolloner
>> wrote:
>>>
>>>
>>>
>>> On Wednesday, August 17, 2016 at 11:06:47 AM UTC+2, dmoisset wrote:

 @Florian
 Would you care to ellaborate? I couldn't find the post you mention
 (although requests is one of the few 3rd party projects that have support 
 at
 the official typeshed repository, https://github.com/python/typeshed )
>>>
>>>
>>> https://lwn.net/Articles/643269/ and https://lwn.net/Articles/643399/ --
>>> might be that things changed by now.
>>
>> --
>> 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 vi

Re: PEP 484 type hinting in Django

[Daniel Moisset]

Thanks for the replies,

As I mentioned, I have already started implementation (and I'm willing to
go through with it, having even some time from my work allocated to do it);
I wasn't aware of the JetBrains plan (it's a nice plus, but I don't depend
on it), and I'll probably do it as external files if the django core team
itself is not interested, but I think it's more beneficial to do it inline.

One clarification is that there is no need to drop 2.7 support to use
inline annotations; there's a python2 compatible way to annotate described
now in PEP484.

What I'd like to do is to get a reading of the room to see if there's some
degree of interest (at least a "I'm curious to see how it looks if you do
the work") before following up with the DEP process. I made a very quick
summary of what I think the benefits would be, but if it's not clear I'd be
happy to ellaborate.

Some key things that have changed since last year (regarding the links
posted by Florian and Tim) are:

* PEP-484 is now approved and standard part of python. The mypy checker is
now under the python project umbrella and getting active maintainance and
backed by key people in the python community
* Having a standard (instead of just a 3rd party tool supporting this)
means that this now annotations can help to interoperate with many tools
(type checkers, editors, documentation generators, refactoring tools), so
the impact in the ecosystem is larger
* There's some evidence that this works on production (people in dropbox
have been using it for ~ a year, according to [1])
* There are several complaints telling that "this won't be actually
optional", but I see no evidence to support it. And in any case those are
arguments around deciding to include this in the language, and that
decision has been made already. But in my experience, annotations help more
in some particular modules/APIs and not in others, so an abvious option is
to add them only where they add value (i.e. increase readbility and clarity
of interfaces)
* Cory Benfield points at some complex types, that (from a quick look) with
new type aliases and overload semantics can probably be described in a much
simpler and readable way. And again, if they don't that function (or that
argument) shouldn't be annotated.
* There's someone volunteering to do the work (me and some colleagues at
Machinalis) :)

I've already been looking at some interfaces in django and I feel that a
lot of them are as not dynamic and polymorphic as requests is, so some
success can be achieved here.

So, how do you guys feel about this? what are the risks/fears that you'd
like to have addressed? do you share my opinion that this will be positive
for both the framework and its users?

Best,

[1] http://pythonpodcast.com/david-greg-mypy.html


On Wed, Aug 17, 2016 at 2:41 PM, Tim Graham  wrote:

> The JetBrains announcement that they want to fund the project isn't a
> guarantee that it'll be implemented. The feature needs to go through the
> normal feature acceptance process, which as Markus said, might involve a
> DEP.
>
> Assuming the idea is accepted, my sense on timing would be to wait until
> January when Django drops support for Python 2.7 and 3.4 in master. Then we
> could use inline annotations rather than the stub files.
>
> Past discussions of type hinting:
> https://groups.google.com/d/topic/django-developers/z_P1TvJ6QG8/discussion
> https://groups.google.com/d/topic/django-developers/xOTmq93YZuQ/discussion
>
> On Wednesday, August 17, 2016 at 5:30:56 AM UTC-4, Florian Apolloner wrote:
>>
>>
>>
>> On Wednesday, August 17, 2016 at 11:06:47 AM UTC+2, dmoisset wrote:
>>>
>>> @Florian
>>> Would you care to ellaborate? I couldn't find the post you mention
>>> (although requests is one of the few 3rd party projects that have support
>>> at the official typeshed repository, https://github.com/python/typeshed
>>> )
>>>
>>
>> https://lwn.net/Articles/643269/ and https://lwn.net/Articles/643399/ --
>> might be that things changed by now.
>>
> --
> 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/b5dcb500-4706-407f-8e42-
> 65944d30ccf5%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  (Contribution

Re: PEP 484 type hinting in Django

[Tim Graham]

The JetBrains announcement that they want to fund the project isn't a 
guarantee that it'll be implemented. The feature needs to go through the 
normal feature acceptance process, which as Markus said, might involve a 
DEP.

Assuming the idea is accepted, my sense on timing would be to wait until 
January when Django drops support for Python 2.7 and 3.4 in master. Then we 
could use inline annotations rather than the stub files.

Past discussions of type hinting:
https://groups.google.com/d/topic/django-developers/z_P1TvJ6QG8/discussion
https://groups.google.com/d/topic/django-developers/xOTmq93YZuQ/discussion

On Wednesday, August 17, 2016 at 5:30:56 AM UTC-4, Florian Apolloner wrote:
>
>
>
> On Wednesday, August 17, 2016 at 11:06:47 AM UTC+2, dmoisset wrote:
>>
>> @Florian
>> Would you care to ellaborate? I couldn't find the post you mention 
>> (although requests is one of the few 3rd party projects that have support 
>> at the official typeshed repository, https://github.com/python/typeshed )
>>
>
> https://lwn.net/Articles/643269/ and https://lwn.net/Articles/643399/ -- 
> might be that things changed by now.
>

-- 
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/b5dcb500-4706-407f-8e42-65944d30ccf5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django.core.mail.outbox and __all__

[Tim Graham]

I believe that would break things:

>>> from django.core.mail import *
AttributeError: module 'django.core.mail' has no attribute 'mailbox'

On Wednesday, August 17, 2016 at 7:30:11 AM UTC-4, IL Ka wrote:
>
> Hello,
>
> ``django.core.mail`` package contains ``__all__`` with list of public 
> symbols, but ``outbox`` is not there. I understand that this field is 
> dynamic, but it confuses user. Should not we add it to ``__all__``?
>
>
>
> Ilya.
>

-- 
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/09e555a8-90f3-4872-a37a-4cbb76249396%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: should blank POST data fallback to use model field defaults?

[Tim Graham]

I think there's a misunderstanding. As the documentation says, 
forms.BooleanField(required=False) is the common case because required=True 
means the checkbox must be checked. It's only confusing in the context of a 
non-browser request where empty POST data might have a different meaning.

https://docs.djangoproject.com/en/stable/ref/forms/fields/#booleanfield

On Wednesday, August 17, 2016 at 7:04:35 AM UTC-4, Michael Foster wrote:
>
> I believe Tom is right. The documentation is trivial but there is a need 
> to raise an error or warning to the user when specifying required=False for 
> boolean fields, as it is nonsensical.
>
> On Tuesday, August 16, 2016 at 12:52:06 AM UTC+1, Tom Christie wrote:
>>
>> It's not perfect but given that it's an inherent limitation of HTML 
>> checkboxes, I don't think that documenting that limitation is that big a 
>> deal.
>>
>> forms.BooleanField(required=False) feels like an odd combination to me in 
>> any case. One way we could potentially help users would be to error in that 
>> case unless an alternate widget is used (We could recommend select or 
>> whatever it is we use for NullBooleanField in this case)
>>
>> We have the same issue in REST framework serializers FWIW. As with 
>> Django<1.10 we treat omission as omission, not blank. And yes, we have to 
>> special-case boolean omission.
>>
>>

-- 
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/cc70b0d2-0d58-4bda-b774-5f1dffb51bf3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

django.core.mail.outbox and __all__

[IL Ka]

Hello,

``django.core.mail`` package contains ``__all__`` with list of public 
symbols, but ``outbox`` is not there. I understand that this field is 
dynamic, but it confuses user. Should not we add it to ``__all__``?



Ilya.

-- 
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/44752676-a831-4fe6-8574-82fcb689ecdc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: should blank POST data fallback to use model field defaults?

[Michael Foster]

I believe Tom is right. The documentation is trivial but there is a need to 
raise an error or warning to the user when specifying required=False for 
boolean fields, as it is nonsensical.

On Tuesday, August 16, 2016 at 12:52:06 AM UTC+1, Tom Christie wrote:
>
> It's not perfect but given that it's an inherent limitation of HTML 
> checkboxes, I don't think that documenting that limitation is that big a 
> deal.
>
> forms.BooleanField(required=False) feels like an odd combination to me in 
> any case. One way we could potentially help users would be to error in that 
> case unless an alternate widget is used (We could recommend select or 
> whatever it is we use for NullBooleanField in this case)
>
> We have the same issue in REST framework serializers FWIW. As with 
> Django<1.10 we treat omission as omission, not blank. And yes, we have to 
> special-case boolean omission.
>
>

-- 
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/749629ad-15fa-44ba-a556-dfa727a8adde%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PEP 484 type hinting in Django

[Florian Apolloner]

On Wednesday, August 17, 2016 at 11:06:47 AM UTC+2, dmoisset wrote:
>
> @Florian
> Would you care to ellaborate? I couldn't find the post you mention 
> (although requests is one of the few 3rd party projects that have support 
> at the official typeshed repository, https://github.com/python/typeshed )
>

https://lwn.net/Articles/643269/ and https://lwn.net/Articles/643399/ -- 
might be that things changed by now.

-- 
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/cc9d0ca4-a95d-498f-9ef7-21bb0c35478e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PEP 484 type hinting in Django

[Daniel Moisset]

Hi

@Alex,

I wasn't aware of the fellowship program, but I've been getting started to
work at this and I already have some minimal things up

I have a repo with type hints (currently just covering the HttpRequest
object and other minor stuff) at https://github.com/machinalis/mypy-django ;
I'm currently working on the HttpResponse object (with that I can already
have some typehinting at my views). To work on it I'm actually doing
annotations on the source code (I have a forked django at
https://github.com/dmoisset/django/tree/typing-requests ), and then
converting those to stub files, In that way I can run the checker against
the actual code and ensure the annotations are consistent.

I was planning to make a comment about these here when they were a bit more
mature with some minimal example, but given that the discussion already got
here I think they may help.

@Markus
If there's interest in the community, I volunteer for the process of
getting in charge of the discussion and drafting of the DEP. I wanted to
know first how the community feels about these.

@Florian
Would you care to ellaborate? I couldn't find the post you mention
(although requests is one of the few 3rd party projects that have support
at the official typeshed repository, https://github.com/python/typeshed )

*
@all

For those of you wondering what all these is about, it's about adding
static type hints to the arguments/result types of the results in Django.
Currently there are 2 ways to do this:

A) As a 3rd party project, providing separate "interface files" that mimic
the ones with django, only with the function/method signatures
B) As inline annotation in the django code (think of it as structured
docstrings)

Option (A) has the benefit of not interfering at all with the project, with
the burden that it's harder to maintain and keep in sync when django makes
new releases; it only helps django users
Option (B) is easy to keep in sync and can help with django development
itself, but it may imply some process changes (integrating a checker into
CI, and in some very specific cases making contributors aware of it).
Another drawback is that given that django still supports python 2, we need
to use the "#type" comments instead of python3 annotations that are quite
uglier.

I've been working doing this for some internal projects at Machinalis and
for a couple open source projects. So let me add a few comments that I
already know that are frequently asked questions:

* This has minimal to zero impact on runtime (probably adding a few
imports). It's comparable to adding docstrings to a module that doesn't
have it. The annotation is for outside analyzer tools (checkers and
linters) running on CI, not on the django project itself
* This does not have to be done project-wide, so it's not a huge
undertaking; the point of gradual typing is that you can work at function
granularity and build up. That's why I've started in small but visible
modules like HttpRequest/HttpResponse.
* In fact, there are some parts of django that will probably not be covered
for a long time (I thinking QuerySets here) because they would need
substantial support from the tool to make sense
* The main goal of this is NOT detecting bugs (tests generally work ok).
The goal is providing accurate documentation about function inputs and
outputs that can help humans (for example people asking themselves "are the
keys of request.FILES bytes or unicode?"), and tools (for example
documentation generators that could expose this info, code editors that can
add autocompletion, etc)
* In a codebase with builtin annotations, it may help detecting simple bugs
more quickly than the test suite; it works well integrated with an editor
(in the same way that tools like pep8/flake8 detect simple things there).
The power here increases as you get more core annotated (but again, it may
work gradually).

I also wanted to reinforce that I'm not asking somebody else to do it... I
need this, so I'm already working on it, but I welcome anyone to join :)

Best,
D.




On Wed, Aug 17, 2016 at 5:08 AM, Alexander Hill  wrote:

> Hi all,
>
> I like the plan to include PEP 484 type hinting in Django, outlined in the
> PyCharm promotion blog post. [1]
>
> Has this proposal been fleshed out much? Is there any extra information
> available anywhere that I've missed? I think this will be great for Django,
> and I'd happily contribute to the effort.
>
> Cheers,
> Alex
>
> [1] https://www.djangoproject.com/weblog/2016/jun/30/
> pycharm-and-django-fundraiser/
>
> --
> 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 th

Re: PEP 484 type hinting in Django

[Florian Apolloner]

I personally do not think that this is something belonging into Django 
itself -- at least not in the current state. The requests (I think) 
maintainers have a good blog post iirc on the current issues.

On Wednesday, August 17, 2016 at 6:08:48 AM UTC+2, Alex Hill wrote:
>
> Hi all,
>
> I like the plan to include PEP 484 type hinting in Django, outlined in the 
> PyCharm promotion blog post. [1]
>
> Has this proposal been fleshed out much? Is there any extra information 
> available anywhere that I've missed? I think this will be great for Django, 
> and I'd happily contribute to the effort.
>
> Cheers,
> Alex
>
> [1] 
> https://www.djangoproject.com/weblog/2016/jun/30/pycharm-and-django-fundraiser/
>

-- 
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/534ff524-135a-433d-b232-1b1d2f56c9f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.