Model Meta inheriting ordering from abstract models

[Podrigal, Aron]

Hi,

While going through the code for ModelBase I came across the following
which I was unable to get it  clear from the documentation.

A model inheriting from a concrete model does not inherit the Meta class of
its parent no matter if it has a Meta of its own. However, it does inherit
2 options, which they are: *ordering* and *get_latest_by*. Even when it has
a Meta of its own, as long as those 2 options have not been overridden
explicitly. By contrast, inheriting from an abstract model inherits the
Meta class of the abstract model when it does not have a Meta class of its
own. What I find unclear, is, when a model inherits from an abstract model
which defines meta.ordering, if the child model also has its own Meta
class, it does not inherit the ordering option from it's parent.

Is this by design


class AbstractModelWithOrdering(models.Model):
name = models.CharField(max_length=255)

class Meta:
ordering = ['-name']
abstract = True


class ExtendAbstractModelWithOrdering(AbstractModelWithOrdering):
class Meta:
db_table = 'extended_abstract_model'


class ConcreteModelWithOrdering(models.Model):
name = models.CharField(max_length=255)

class Meta:
ordering = ['-name']


class ExtendConcreteModelWithOrdering(ConcreteModelWithOrdering):
class Meta:
db_table = 'extended_concrete_model'




class InheritedOrderingTests(SimpleTestCase):
def test_inheriting_from_abstract_with_meta_inherits_ordering(self):
self.assertEqual(ExtendAbstractModelWithOrdering._meta.ordering,
['-name'])

def test_inheriting_from_concrete_with_meta_inherits_ordering(self):
self.assertEqual(ExtendConcreteModelWithOrdering._meta.ordering,
['-name'])



==
FAIL: test_inheriting_from_abstract_with_meta_inherits_ordering
(model_meta.tests.InheritedOrderingTests)
--
Traceback (most recent call last):
  File "/home/aron/django/django_repo/tests/model_meta/tests.py", line 280,
in test_inheriting_from_abstract_with_meta_inherits_ordering
self.assertEqual(ExtendAbstractModelWithOrdering._meta.ordering,
['-name'])
AssertionError: Lists differ: [] != ['-name']

Second list contains 1 additional elements.
First extra element 0:
-name

- []
+ ['-name']

--
Ran 2 tests in 0.001s

FAILED (failures=1)


-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
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/CANJp-yiad%2BOhHQ06giAoaFWEBthkuj4%3DhjUYGHOhpfUx9o9hbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Announcing Django-Zappa - Serverless Django on AWS Lambda + API Gateway

[Cristiano Coelho]

Hello, I would like to suggest that you include the limitations AWS Lambda 
and API Gateway has, since I have used them and it is not suitable for 
every use case.

For example, one of the biggest limitations is that an Lambda can run for 
at most 5 minutes, but if paired with API Gateway, it can only run for 1 
minute before returning a time out, I know 1 minute is quite a lot, but if 
you have any kind of multimedia processing (like uploading a file, or 
downloading one that is generated on the server like a PDF) you will need 
to re write some code to use other amazon services such as S3.
Other limitations include things such as 100 concurrent requests at a time 
and 500 requests per second, payload for request and respose size limits of 
6mb and other things that can be read here 
http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html

Some (most) of those limits can be increased by request to Amazon.

Leaving the limitations aside, AWS Lambda is really a great product I 
highly recommend!

El lunes, 8 de febrero de 2016, 11:23:47 (UTC-3), Rich Jones escribió:
>
> Hey guys!
>
> (I also made this post to django-users, but I think the discussion here 
> can be about ways that we can improve Django to work better on AWS Lambda. 
> Forgive the double-post.)
>
> I'm pleased to announce the release of Django-Zappa - a way to run 
> serverless Django on AWS Lambda + API Gateway.
>
> Now, with a single command, you can deploy your Django apps in an 
> infinitely scalable, zero-configuration and incredibly cheap way!
>
> Read the announcement post here: 
> https://gun.io/blog/announcing-zappa-serverless-python-aws-lambda/
> Watch a screencast here: 
> https://www.youtube.com/watch?v=plUrbPN0xc8=youtu.be
> And see the code here: https://github.com/Miserlou/django-zappa
>
> Comments, questions and pull requests are welcome!
>
> It seems quite performant already, but I bet there are ways that we can 
> improve Django to work better on Lambda. 
>
> Enjoy,
> Rich Jones
>

-- 
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/d1c0510e-061b-4e7b-be7e-874d5ad61903%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: View permissions to admin

[Tim Graham]

I think a view permission is reasonably within the scope of the admin, 
although I'm a bit nervous that we'll forget about it in some future 
feature and end up introducing a security issue.

Since the topic comes up from time to time, I submitted a PR to remove 
"production-ready interface" from the admin's intro and temper expectations 
a bit: https://github.com/django/django/pull/6104

On Monday, February 1, 2016 at 7:20:37 AM UTC-5, Olivier Dalang wrote:
>
> Hi, 
>
> +1 for view permission and Petr's rationale
>
> There's one use case where missing the view permission should even be 
> considered a bug: when you have foreign key with the raw id widget, 
> currently the user gets a 403 error in the popup if he doesn't have edit 
> permission on the related model.
>
> Best,
>
> Olivier
>
>
> On 31 Jan 2016 17:10, "Petr Dlouhý"  
> wrote:
>
>> Hi Markus, Adam,
>>
>> I looked to Django admin documentation (
>> https://docs.djangoproject.com/en/1.9/ref/contrib/admin/). I don't see 
>> anything discouraging from such usage, but rather I see encouraging for 
>> usage as interface for content managers:
>>
>> "One of the most powerful parts of Django is the automatic admin 
>> interface. It reads metadata in your model to provide a powerful and 
>> production-ready interface that content producers can immediately use to 
>> start adding content to the site. In this document, we discuss how to 
>> activate, use and customize Django’s admin interface."
>>
>> I totally agree with that quote, Django admin is one of the top things 
>> that I love at Django. For it flexibility, easy development and usefulness. 
>> Why not to make Django strengthenesses even stronger? I use it in such ways 
>> and I am not aware about any "fiddling with the internals". The view 
>> permissions was first such case.
>>
>> If Django admin usage for such purposes is not intended, I would expect 
>> to see big fat warning as a first thing on that page.
>>
>> View permissions in admin seems to me as something very natural that is 
>> missing there. The implementation of that is very lightweight and nicely 
>> fitting - I mostly only added what was missing there. I wouldn't call that 
>> hacking.
>> Yes, I was thinking of making an independent application, but that would 
>> probably be very difficult and would require to copy some code of the 
>> Django internals. That would require big hacking!
>>
>> 2016-01-31 17:49 GMT+01:00 Adam Johnson 
>> :
>>
>>> Hi,
>>>
>>> At YPlan we've hacked in view permissions to the admin, exactly because 
>>> of the reasons Markus talked about - it's the front end we've built for 
>>> employees, done rather than building a proper process-based interface. I 
>>> think it could just about be done in a third-party package (It might rely 
>>> on a patchy.patch  call though), 
>>> rather than incorporating it into Django - have you considered this? At 
>>> this point we're all in preference of a better toolbox for building 
>>> internal tools, as Markus is suggesting, rather than "improving" the admin.
>>>
>>> Adam
>>>
>>> On Thursday, January 28, 2016 at 6:17:26 AM UTC, Markus Holtermann wrote:

 Hi Petr, all,

 I managed to find some time to look into your PR (updated link: 
 https://github.com/django/django/pull/5297) and the related issue: 
 https://code.djangoproject.com/ticket/8936 .
 Also, related discussion: 
 https://groups.google.com/d/topic/django-developers/rZ5Pt9R94d4/discussion 
 and issues: https://code.djangoproject.com/ticket/820 and 
 https://code.djangoproject.com/ticket/17295

 First of all, thank you for your your contribution and persistence.

 I think Django should provide an easy way to get a read-only view of 
 your data in the database. However, I don't really like the integration 
 into contrib.admin . As it stands now, people commonly use the admin as a 
 front end for their employees instead of building a proper 
 process-oriented 
 interface. This may work to some degree but it's not uncommon that 
 developers need to fiddle with the internals of the admin to make specific 
 things work. Adding a read-only view to the admin would encourage people 
 even more to use the admin for reasons where they shouldn't.

 I'd prefer an approach on a different level where Django gains a proper 
 (de)serialization implementation. The implementation would e.g. leverage 
 content negotiation to define the output, e.g. JSON, XML, HTML, etc.

 What I'm pretty much saying is, I'd rather see a proper django.rest (or 
 whatever we wanna call it) instead of a feature on top of the convoluted 
 admin which provides only half of what people probably want and use.

 Cheers,

 /Markus

 On Wednesday, August 26, 2015 at 9:49:58 PM UTC+10, Petr Dlouhý wrote:
>
> Hello all,
>

Re: remove support for unsalted password hashers?

[Tim Graham]

Thanks for the feedback everyone. I've created a few action items:

https://code.djangoproject.com/ticket/26187 - Remove weak password hashers 
from the default PASSWORD_HASHERS setting
https://code.djangoproject.com/ticket/26188 - Document how to wrap password 
hashers
https://github.com/django/djangoproject.com/issues/632 - Use a wrapped 
password hasher to upgrade SHA1 passwords

On Saturday, February 6, 2016 at 3:56:00 AM UTC-5, Curtis Maloney wrote:
>
> I kept meaning to weigh in on this... but all my points have been made. 
>
> It sounds like the middle ground is to: 
>
> 1) remove them from the default list 
> 2) keep them in the codebase 
> 3) make them noisy (raise warnings) 
> 4) provide docs/tools on how to upgrade 
>
> Then we get "secure by default" (1), as well as "encouraging upgrades" 
> (3), whilst also "supporting slow-to-update installs" (4), and 
> "encouraging best practices" (3). 
>
>
> -- 
> C 
>
>
> On 06/02/16 19:51, Aymeric Augustin wrote: 
> > Yes, that would be good from the “security by default” standpoint. This 
> > would also allow us to trim the full list of hashers which is repeated 
> > several times in the docs. 
> > 
> > -- 
> > Aymeric. 
> > 
> >> On 6 févr. 2016, at 00:03, Tim Graham  >> > wrote: 
> >> 
> >> I would guess most users aren't customizing the default list of 
> >> hashers, so I'd rather remove weak hashers from the PASSWORD_HASHERS 
> >> setting and let anyone who needs to use a weak hasher define their own 
> >> setting (at which point a warning probably isn't needed). Does that 
> >> seem okay? 
> >> 
> >> On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin 
> wrote: 
> >> 
> >> Adding a check for weak password hashers could be a good 
> >> compromise to drive attention to the issue but make it reasonably 
> >> easy to ignore it if you need MD5 for compatibility with other 
> >> systems. 
> >> 
> >> -- 
> >> Aymeric. 
> >> 
> >>> On 5 févr. 2016, at 21:11, Sergei Maertens  >>> > wrote: 
> >>> 
> >>> This is my main concern as well. I often migrate old Joomla or 
> >>> other PHP things that use md5, and it's really convenient that 
> >>> Django upgrades the passwords for free for me. 
> >>> 
> >>> Although I guess I could just write the hasher as part of the 
> >>> project and add it to the setting, but then that's an additional 
> >>> burding because you need to keep track of potential new hashers 
> >>> that get added in the default settings. 
> >>> 
> >>> On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń 
> wrote: 
> >>> 
> >>> Will I still be able to implement unsalted hasher if I so 
> desire? 
> >>> 
> >>> Don't get me wrong, I understand thats pretty crappy way to 
> >>> store password, but there are times when you inherit large 
> >>> set of data from site that you are moving from some old PHP 
> >>> contraption that happens to be around since 2006, is big 
> >>> (>100 users), ran by company that dominates one of 
> >>> nation's markets and says "absolutely no" on making all those 
> >>> housewifes reset passwords, and your passwords happen to use 
> >>> md5(md5(pass) + md5(pass)) for passwords? 
> >>> 
> >>> 
> >>> -- 
> >>> 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/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com
>  
> >>> <
> https://groups.google.com/d/msgid/django-developers/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
> >>> 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 

Re: We should be given the possibility of turning OFF the migrate-automatic run of "The CREATE EXTENSION postgis command"

[Matlau Issu]

It think i deleted the answer of someone else. If this is the case, i am 
really sorry I did not do it on purpose

-- 
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/782e9e21-e79d-4af5-bba0-7b5dc58b2eb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: We should be given the possibility of turning OFF the migrate-automatic run of "The CREATE EXTENSION postgis command"

[James Addison]

On Mon, Feb 8, 2016 at 9:39 AM, Matlau Issu  wrote:

> I mean, if i work with a postgresql whose version is lower than 9.1, the
> automatic run of "CREATE EXTENSION postgis" crashes everything !
> Indeed there is no extension concept for versions lower than 9.1.
>

https://docs.djangoproject.com/en/1.9/ref/databases/#postgresql-notes -
PostgreSQL < 9.1 is not supported. Your options to are to upgrade
PostgreSQL or downgrade Django. Obviously, the former is recommended.


-- 
[image: photo] James Addison
e: add...@gmail.com

  

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

We should be given the possibility of turning OFF the migrate-automatic run of "The CREATE EXTENSION postgis command"

[Matlau Issu]

Hi guys !

Are you definitely ok with the "CREATE EXTENSION postgis" command which is 
now automatically run during the migrate 
 
process ?

I mean, if i work with a postgresql whose version is lower than 9.1, the 
automatic run of "CREATE EXTENSION postgis" crashes everything !
Indeed there is no extension concept for versions lower than 9.1.

Hence we should be given the possibility of turning OFF the 
migrate-automatic run of this command, at least for a while.

For example in settings.py

POSTGRESQL_EXTS_AUTO_CREATION = True# Would be False in my case 
!!!

I have to go back to django.VERSION <1.8 (since this automatic run is a 
change of 1.8 : 
https://docs.djangoproject.com/en/1.8/ref/contrib/gis/install/postgis/)

Is there something i dont see ??





-- 
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/04b28505-2798-4152-a505-97ba5024f5fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Index expressions

[Tim Graham]

I added "Custom indexes" to the ideas list at 
https://code.djangoproject.com/wiki/SummerOfCode2016. Feel free to revise 
the description or add yourself as a possible mentor.

On Sunday, February 7, 2016 at 6:26:38 AM UTC-5, Josh Smeaton wrote:
>
> There are many places that expressions can extend to, and I think indexes 
> would make a really good candidate. There are a few things that need to 
> happen to make this work though.
>
> - create meta.indexes to store { index_name: IndexType('field') }
> - internally translate any db_index=True to the appropriate key: val in 
> above meta.indexes
> - internally translate index_together into meta.indexes
> - use compiler to generate the sql
> - ensure that migrations handle these new indexes properly
>
> I would also suggest that index names be queried to ensure we're not 
> trying to use existing names. Not sure if migrations already do this, but I 
> seem to remember something about not being able to track index names. Am I 
> totally off base?
>
> This idea would actually make a really good GSoC (or similar..) project. 
> Is there much interest from the community in custom indexes?
>
> On Sunday, 7 February 2016 22:11:59 UTC+11, Curtis Maloney wrote:
>>
>>
>> So, in #django recently there was a discussion about adding an index on 
>> a date field for just the year. 
>>
>> I know the idea was raised some time ago, and several ideas on the 
>> syntax were expressed.  But most of that focused on different types of 
>> indices - not on indexing expressions. 
>>
>> It occurred to me that with the recent advances in expression syntax, it 
>> should be fairly easy to add an indexes list to Meta to define complex 
>> expressions. 
>>
>> Input? 
>>
>> -- 
>> C 
>>
>

-- 
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/b366267c-2d21-40f6-a4d7-48aba9eaaba6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Detect languages for a short text and files

[Tim Graham]

This mailing list is for the development of Django itself. Please write to 
django-users for usage questions (but this question doesn't seem to be 
Django related).

On Monday, February 8, 2016 at 7:06:43 AM UTC-5, Allison A. wrote:
>
> I am looking for a python package for detecting language. So far, 
> lang-detect, langid are recommended. How accurate are they? Is there any 
> better package than these? 
>
> 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/ca20f44f-3adb-4cab-bd61-f38a271f500b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django template modules compiled with cython

[Adam Johnson]

Hey Cristiano

Yeah it's a shame it didn't work out.

In our case, we would love to try Jinja2, but we can't, because the slow 
pages are in the Django Admin rather than our own code :(

For our main site we do use javascript templates - clientside as you say, 
except we call out to a node.js server to render the first page view 
"isomorphically" so Google likes us.

Pyjion does look intereseting, thanks for the link.

On Saturday, February 6, 2016 at 12:28:16 AM UTC, Cristiano Coelho wrote:
>
> Hi Adam,
>
> I'm sorry it didnt'work out after all, let me tell you that Python itself 
> is quite slow and the template engine has some good overhead as well making 
> this slowlyness even worse, greatly noticed on big or nested loops. Also, 
> 10% increase seems quite low to be important.
>
> I think that if you really want a performance boost you have a few options 
> (all quite bad though):
>
> - Use PyPy rather than python, this one is quite complicated if you have 
> cloud deplyoments or lots of 3rd party libraries.
> - Use Jinja2 template engine which is said to be faster
> - Re write the template engine or parts in actual C code as C extension 
> (this is very complicated)
> - Stop using templates completely (only keep it for a start page) and move 
> to client side templating such as AngularJS (the web is moving towards this 
> with client side + REST Api, this is a highly performant and scalable 
> option compared to server side templating)
> - There's a new Microsoft project called Pyjion, which says they have 
> implemented a JIT API for CPython, adding JIT support to python while still 
> being 100% compatible with it, this is quite different from PyPy approach. 
> I believe this is quite alpha yet but looks promising: 
> https://github.com/Microsoft/Pyjion
>
> El viernes, 5 de febrero de 2016, 13:23:59 (UTC-3), Adam Johnson escribió:
>>
>> Hi guys,
>>
>> I work with Alex here at YPlan. We deployed a tidied updated version of 
>> Alex's code as django-speedboost, since it looked promising in local 
>> profiling. You can see the code here: 
>> https://github.com/YPlan/django-speedboost . It uses a Cythonized 
>> version of Django 1.8.8's template engine, and passes Django 1.8.8's test 
>> suite. This is also compatible with 1.8.9, since there were no template 
>> changes, but not 1.9.x (as far as we know!).
>>
>> However, we did take it out of production recently though. The speed 
>> boost we could measure locally with profiling, about 10% on whole page 
>> time, didn't seem to translate into a speed boost in production. We don't 
>> really know why, but since it's quite hackish and requires maintenance, 
>> we've stopped using it. Just wanted to let everyone know where we got.
>>
>> Thanks,
>>
>> Adam
>>
>> On Tuesday, December 15, 2015 at 8:51:58 AM UTC, Florian Apolloner wrote:
>>>
>>>
>>>
>>> On Monday, December 14, 2015 at 3:53:50 PM UTC+1, Alexandru Damian wrote:

 I am not really convinced that replacing the whole file is a good idea. 
> In my experience one gets better results when using Cython by 
> strategically 
> replacing single functions and rewriting those in C directly. 
>

 This is the actual approach I am taking, but at class level. I 
 selectively choose the base classes and convert those to Cython language; 
 the modules are packaged in as a whole to make packaging easier. 

>>>
>>> Well, defaulttags.pyx and base.pyx seems to indicate to me that the 
>>> whole files are compiled? I understand that this is most likely due to 
>>> cdefing some base classes -- therefore you need a C-context. But that is 
>>> what I ment with replacing the whole files.
>>>
>>> Cheers,
>>> Florian 
>>>
>>

-- 
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/34c47e83-5019-49a3-9eaa-4f61fb8bec72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Announcing Django-Zappa - Serverless Django on AWS Lambda + API Gateway

[Rich Jones]

Hey guys!

(I also made this post to django-users, but I think the discussion here can 
be about ways that we can improve Django to work better on AWS Lambda. 
Forgive the double-post.)

I'm pleased to announce the release of Django-Zappa - a way to run 
serverless Django on AWS Lambda + API Gateway.

Now, with a single command, you can deploy your Django apps in an 
infinitely scalable, zero-configuration and incredibly cheap way!

Read the announcement post here: 
https://gun.io/blog/announcing-zappa-serverless-python-aws-lambda/
Watch a screencast here: 
https://www.youtube.com/watch?v=plUrbPN0xc8=youtu.be
And see the code here: https://github.com/Miserlou/django-zappa

Comments, questions and pull requests are welcome!

It seems quite performant already, but I bet there are ways that we can 
improve Django to work better on Lambda. 

Enjoy,
Rich Jones

-- 
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/e211b4de-0910-4bf6-ac72-6a6cc39de9f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Detect languages for a short text and files

[Allison A.]

I am looking for a python package for detecting language. So far, 
lang-detect, langid are recommended. How accurate are they? Is there any 
better package than these? 

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/94b525b4-752e-45e1-883c-77a91bc38f6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.