Re: PEP 484 type hinting in Django

[Markus Holtermann]

Hi Alex,

I haven't heard of any discussion on that topic. I'd certainly like to
have a DEP before we start implementing it, though.

Cheers,

Markus

On Wed, Aug 17, 2016 at 04:08:29AM +, 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 the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BKBOKzHPhsqeZGF4ebcc2eCuMjpSsN4MfWFAMxzFXjU%3D2-isw%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/20160817051224.GE1856%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

PEP 484 type hinting in Django

[Alexander Hill]

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/CA%2BKBOKzHPhsqeZGF4ebcc2eCuMjpSsN4MfWFAMxzFXjU%3D2-isw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any inerest in Zlib pre-compressed HTML generator responses?

[Bobby Mozumder]

> On Aug 16, 2016, at 2:16 AM, Curtis Maloney  wrote:
> 
> On 16/08/16 09:10, Bobby Mozumder wrote:
>> Hi,
>> 
>> I also use generators for my views, and I use Django’s streaming views
>> with my generators to stream responses, so that the web browser receives
>> early responses and start rendering immediately before the view is
>> completely processed.  The web browser receives the first HTML fragment
>> before I even hit the database.
> 
> The hazard here is if anything raises an exception you've already sent 
> headers to say it didn't... typically this results in pages terminating part 
> way through.
> 
> Other than this, it is certainly a great way to overlap some transport 
> latency with work.  I've done the same with a generator-based JSON serialiser.
> 

I do have the option to query the database once to check if a URL is valid, 
before returning a response. This would also read most of the page’s data in 
the same query.  But right now I’m just letting the URL resolver figure out if 
the page is valid before it hits the database, which can lead to incorrect 
responses given a mangled URL.

All other queries after the primary query are for secondary data - the 
“additional links”, the “categories”, the “further headlines” type of data, and 
those queries would only work if the primary query works as well.  

-bobby

-- 
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/19C8C0A2-76B7-4807-A2F9-06DCB5ED26E2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any inerest in Zlib pre-compressed HTML generator responses?

[Bobby Mozumder]

I’ll look into what it would take to make it a separate package, to make it 
more generic and usable by all.

I was pushing for this to be part of the core to overcome Django’s 
“slow-by-default” impression.  My first version of this site had access times 
in the several second range, and it took a while to get that down using things 
like select_related and other optimizations.  

This was especially a problem since i came to Django as a replacement to speed 
up our old PHP-based site that went down during a high-traffic moment.   I 
finally had to toss out the Django the template system and ORM for something 
custom.  

Django really should be “high-speed-out-of-the-box” by default.

-bobby

> On Aug 16, 2016, at 2:14 AM, Jani Tiainen  wrote:
> 
> Hi,
> 
> To me it looks like this can live just fine outside Django core as a separate 
> package since it doesn't look that it requires any changes to Django core 
> itself. So for the community it doesn't need to be within Django core, you 
> can already do it for all existing and future versions - which would provide 
> nice ground to prove that your solution is good and useful for others as well.
> 
> On 16.08.2016 02:10, Bobby Mozumder wrote:
>> Hi,
>> 
>> I’ve been using zlib compression on my custom view responses on my site 
>> (https://www.futureclaw.com ).  I do this 
>> before I even cache, and I store the compressed responses in my Redis cache. 
>>  This effectively increases my Redis cache size by about 10x.  It also 
>> reduces response times from my HTTP server by 10s of milliseconds, since my 
>> web server doesn’t have to compress on-the-fly for cached responses - the 
>> view fragments are served directly from the Redis cache.
>> 
>> I also use generators for my views, and I use Django’s streaming views with 
>> my generators to stream responses, so that the web browser receives early 
>> responses and start rendering immediately before the view is completely 
>> processed.  The web browser receives the first HTML fragment before I even 
>> hit the database.
>> 
>> Ultimately my page load times are ridiculously fast, especially for a fully 
>> graphically intensive site.  For full cache miss, it might take 15ms to 
>> generate a page.  For a cache hit, it might take .3ms.  For a full page load 
>> end-user, which loads all fonts and graphics, I'm down to 381ms, faster than 
>> 98% of all sites (it was several seconds before).  See: 
>> https://tools.pingdom.com/#!/cHCL3d/https://www.futureclaw.com 
>> 
>> 
>> (BTW I plan on reducing the full-page load times down to the 100-200ms range 
>> using HTTP/2 server push)
>> 
>> Anyways, is this feature of interest to the Django community for perhaps the 
>> next version?
>> 
>> Here is the relevant portion directly lifted from my code as an example.  I 
>> made this earlier this year, and I’m not sure how much this needs to be 
>> changed for use by Django itself, especially considering I don’t use the 
>> Django template system or ORM:
>> 
>> class ZipView(View):
>> 
>> level = 9
>> wbits = zlib.MAX_WBITS | 16
>> 
>> decompressor = zlib.decompressobj(wbits=wbits)
>> 
>> @staticmethod
>> def store(compressor,key,data,time=9,end=False):
>> zData = compressor.compress(data)
>> if end == False:
>> zData += compressor.flush(zlib.Z_FULL_FLUSH)
>> else:
>> zData += compressor.flush(zlib.Z_FINISH)
>> cache.set(key, zData, time)
>> return zData
>> 
>> def inflate(self,decompressor,data):
>> return self.decompressor.decompress(data)
>> 
>> pageData = []
>> 
>> def getPageData(self,slug=None):
>> pass
>> 
>> def generator(self,request,slug=None,compress=True):
>> tuple = []
>> compressor = False
>> decompressor = False
>> 
>> zData = cache.get('pStart')  #pStart contains zlib header.  Header 
>> is needed.
>> if zData is None:
>> html = bytes(self.get_page_start_stream(),'utf-8')
>> compressor = zlib.compressobj(level=self.level, wbits=self.wbits)
>> zData = self.store(compressor,'pStart',html,time=None)
>> else:
>> if compress == False:
>> decompressor = zlib.decompressobj(wbits=self.wbits)
>> html = decompressor.decompress(zData)
>> if compress == False:
>> zData = html
>> yield zData
>> 
>> pageKey = self.getPageKey(slug)
>> zPageData = cache.get(pageKey)
>> if zPageData is None:
>> expire = 3600
>> zPage = b''
>> self.getPageData(slug)
>> 
>> #Fragment tuples contain HTML generator & associated parameters, 
>> as well as cache settings for each fragment.
>> for tuple in self.fragments(request):
>> if tuple[2]:
>>

Re: Support for `Q` objects in `get_or_create` and `update_or_create`

[Flavio Curella]

It didn't occur to me that it could be done that way. Thanks!

I'm closing the ticket as 'invalid'


On Tuesday, August 16, 2016 at 2:03:02 PM UTC-5, charettes wrote:
>
> Hi Flavio,
>
> Is there a reason we can't document chaining filter() with these methods 
> when
> querying with Q() objects?
>
> Person.objects.filter(
> Q(first_name='George') | Q(first_name='Bruce')
> ).get_or_create(defaults={'last_name': 'Harrison'})
>
> If `defaults` was stil only passable as a kwarg this could have worked but 
> at
> this point I don't think it's worth the additionnal complexity as there's 
> no way
> to introduce a fully backward compatible API without deprecating passing
> `defaults` as the first arg.
>
> Even if we were to agree on a new unlikely used kwarg name to specify the 
> query
> object the `(get|update)_or_create` APIs would end up disgressing from the 
> `filter()`
> and `get()` ones which is the main objective of this proposed change I 
> beleive.
>
> Simon
>
> Le mardi 16 août 2016 13:57:25 UTC-4, Flavio Curella a écrit :
>>
>> I'm thinking about adding support for `Q` to `get_or_create` and 
>> `update_or_create`. I've summarized my thoughts at 
>> https://code.djangoproject.com/ticket/27070. 
>>
>>
>> I have a couple of unsolved question; the most critical is the one Tim 
>> raises: if we were to add another keyword argument to those methods, how 
>> much of an impact will it have? Can we find a name that we can be 
>> reasonably confident is not used as a model field by anybody (or a _very_ 
>> small number of users)?
>>
>>
>> Thanks,
>> –Flavio.
>>
>

-- 
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/164e44aa-6133-470a-a178-438d8d772497%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for `Q` objects in `get_or_create` and `update_or_create`

[charettes]

Hi Flavio,

Is there a reason we can't document chaining filter() with these methods 
when
querying with Q() objects?

Person.objects.filter(
Q(first_name='George') | Q(first_name='Bruce')
).get_or_create(defaults={'last_name': 'Harrison'})

If `defaults` was stil only passable as a kwarg this could have worked but 
at
this point I don't think it's worth the additionnal complexity as there's 
no way
to introduce a fully backward compatible API without deprecating passing
`defaults` as the first arg.

Even if we were to agree on a new unlikely used kwarg name to specify the 
query
object the `(get|update)_or_create` APIs would end up disgressing from the 
`filter()`
and `get()` ones which is the main objective of this proposed change I 
beleive.

Simon

Le mardi 16 août 2016 13:57:25 UTC-4, Flavio Curella a écrit :
>
> I'm thinking about adding support for `Q` to `get_or_create` and 
> `update_or_create`. I've summarized my thoughts at 
> https://code.djangoproject.com/ticket/27070. 
>
>
> I have a couple of unsolved question; the most critical is the one Tim 
> raises: if we were to add another keyword argument to those methods, how 
> much of an impact will it have? Can we find a name that we can be 
> reasonably confident is not used as a model field by anybody (or a _very_ 
> small number of users)?
>
>
> Thanks,
> –Flavio.
>

-- 
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/86589b5a-a2ad-4074-87e5-2f098491206f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Support for `Q` objects in `get_or_create` and `update_or_create`

[Flavio Curella]

I'm thinking about adding support for `Q` to `get_or_create` and 
`update_or_create`. I've summarized my thoughts at 
https://code.djangoproject.com/ticket/27070. 


I have a couple of unsolved question; the most critical is the one Tim 
raises: if we were to add another keyword argument to those methods, how 
much of an impact will it have? Can we find a name that we can be 
reasonably confident is not used as a model field by anybody (or a _very_ 
small number of users)?


Thanks,
–Flavio.

-- 
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/b4c68e65-ea18-4c90-97ed-b9be099fff8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code Updates - Class based indexes

[thinkwelldesigns]

Thank you, akki, for this project! Have enjoyed following your progress. 
It'll be something I'm going to make significant use of.

-- 
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/bc1cd9c7-7775-4f26-a236-742581294474%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code Updates - Class based indexes

[akki]

   
   - Add support for column ordering (ASC/DESC) in class based indexes - 
   !6982 , #20888 
   
   The PR has been merged. More on using it over here 
   .
   
   - Resolve bug when unique_together was dropped along with it's field - 
   !7038 , #26180 
   
   Added tests for the new operation. WIP.
   
   - Add support for GIN indexes - !7046 
   , #27030 
   
   You can use GIN indexes now using the new GinIndex 
   
 
index 
   class (and install btree_gin extension using the BtreeGinExtension 
   

 
   operation, if required.)
   
   - Take indexes into account in inspectdb command
   Updated/completed earlier code
   Ticket - https://code.djangoproject.com/ticket/27060
   PR - https://github.com/django/django/pull/7083
   
   
   

On Tuesday, 9 August 2016 01:30:54 UTC+5:30, akki wrote:
>
>
>- Introduce Meta.indexes - !6857 
>, #26808 
>
>The PR  has been merged. 
>Now class based indexes can be added using Meta.indexes 
>
> 
>.
>
>- Add support for column ordering (ASC/DESC) in class based indexes - 
>!6982 , #20888 
>
>Resolve test failures on Oracle
>Update according to review suggestions
>
>- Resolve bug when unique_together was dropped along with it's field - 
>#26180 
>Solve with another approach by introducing *[Add|Remove]UniqueTogether* 
>operations and removing *generate_altered_unique_together* method of 
>*migrations.Autodetector*
>PR - https://github.com/django/django/pull/7038
>
>- Add support for GIN indexes
>Add *BtreeGinExtension* operation to *contrib.postgres* to create 
>btree_gin extension
>Add *GinIndex* to *contrib.postgres.indexes*
>Ticket - https://code.djangoproject.com/ticket/27030
>PR - https://github.com/django/django/pull/7046
>
>
>
> On Tuesday, 2 August 2016 11:12:27 UTC+5:30, akki wrote:
>>
>>
>>
>>- Add support for column ordering (ASC/DESC) in class based indexes
>>Completed - tests, docs, code
>>PR - https://github.com/django/django/pull/6982
>>
>>- Implement Hash index class
>>Add capability to get type of index in introspection (required for 
>>testing this feature)
>>Completed - Add tests, docs, code
>>PR - https://github.com/django/django/pull/6995
>>Ticket - https://code.djangoproject.com/ticket/26974
>>
>>- Some minor changes in !6857 
>>
>>
>> Other than these, I also had a look at btree_gin indexes and extensions 
>> but haven't started the implementation yet.
>>
>> On Wednesday, 27 July 2016 20:26:38 UTC+5:30, akki wrote:
>>>
>>> Hi Jani
>>>
>>> Thanks a lot for offering help. I did face some issues with the Oracle 
>>> setup in the beginning but was able to resolve them yesterday. :)
>>> You are most welcomed to review the PR and offer any suggestions for 
>>> improvement at https://github.com/django/django/pull/6982/. The work 
>>> related to the feature is in progress but the introspection-related work is 
>>> mostly complete.
>>>
>>> Regards
>>> Akshesh(akki)
>>>
>>> On Tuesday, 26 July 2016 16:47:32 UTC+5:30, Jani Tiainen wrote:

 Hi,

 On 26.07.2016 04:28, akki wrote:



- Fixed #24442  - 
Improved schema's index name creating algorithm
Updated !6898  to take 
all column names into account while creating index name 


- Add support for column ordering (ASC/DESC) in class based indexes
Somewhat provides the feature requested in #20888 

WIP code on my branch - 
https://github.com/akki/django/commits/gsoc-indexes-order
Modifying introspection of all databases to return column order as 
well (required for testing) -- implementation for Oracle remaining.


 If you get stuck with Oracle I can lend a hand to help to figure out 
 the details.


- Implement Hash index class
WIP implementation at