Re: websockets

[Jonathan Slenders]

Maybe it's worth noting that Guido is working on a Tulip, a specification 
for an asynchronous API in Python 3, this to get some consensus. Right now, 
there is almost zero compatibility between al the different approaches: 
twisted, tornado, gevent, etc...

If we decide to go for one technology, better be future proof.

Gevent has some issues. It's doing fine most of the time, but the monkey 
patch approach could really break some stuff.
I like something like Twisted's wsgi container and callfromthread. However, 
I think Twisted it way to hard for the average Django user. It's not really 
intuitive, but hopefully, Tulip will provide us with a nicer API.


Le mardi 16 avril 2013 21:25:08 UTC+2, Jacob Kaplan-Moss a écrit :
>
> Hi Ashwin - 
>
> On Tue, Apr 16, 2013 at 2:10 PM, Ashwin Kumar 
>  
> wrote: 
> > is there any way to implement websockets in django? 
> >  if not, any other packages to combine with django. 
>
> There are quite a few third-party apps and demos out there, so many 
> I've lost track. I recommending searching GitHub. 
>
> >  is there any future plan to implement it in django core? 
>
> I hope so; it was a topic of much discussion at DjangoCon. In the last 
> year, there've been a couple of demos put together by core developers: 
>
> * https://github.com/ptone/django-live 
> * https://github.com/aaugustin/django-c10k-demo/ 
>
> So I think I could sum up the current state as this: 
>
> * Most of us would like to see some sort of real-time support in Django. 
> * There's proof that it's possible technically. 
> * But there's little-to-no consensus on what form this would take, or 
> how to implement it. 
>
> It's probably going to take some time and a great deal of effort to 
> come together on that last point. In the meantime, like I said there 
> are a ton of different apps, demos, and utilities out there, so you 
> should be able to put together a "real-time" app without too many 
> issues. But for something more holistic... it could take a while. 
>
> Jacob 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: websockets

[Jacob Kaplan-Moss]

Hi Ashwin -

On Tue, Apr 16, 2013 at 2:10 PM, Ashwin Kumar  wrote:
> is there any way to implement websockets in django?
>  if not, any other packages to combine with django.

There are quite a few third-party apps and demos out there, so many
I've lost track. I recommending searching GitHub.

>  is there any future plan to implement it in django core?

I hope so; it was a topic of much discussion at DjangoCon. In the last
year, there've been a couple of demos put together by core developers:

* https://github.com/ptone/django-live
* https://github.com/aaugustin/django-c10k-demo/

So I think I could sum up the current state as this:

* Most of us would like to see some sort of real-time support in Django.
* There's proof that it's possible technically.
* But there's little-to-no consensus on what form this would take, or
how to implement it.

It's probably going to take some time and a great deal of effort to
come together on that last point. In the meantime, like I said there
are a ton of different apps, demos, and utilities out there, so you
should be able to put together a "real-time" app without too many
issues. But for something more holistic... it could take a while.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

websockets

[Ashwin Kumar]

hi,

is there any way to implement websockets in django?
 if not, any other packages to combine with django.
 is there any future plan to implement it in django core?

With Best
-Ashwin.
+91-9959166266

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[GSoC 2013] Revamping validation functionality proposal

[Christopher Medrela]

I would like to participate in Google Summer of Code this year. I've 
written proposal for "revamping validation functionality" idea. It's 
available as a gist: 
https://gist.github.com/chrismedrela/82cbda8d2a78a280a129 . Below, I'm 
pasting the proposal. Feel free to criticize it.

*Table of content*

1. *Abstract* 1.1 Drawbacks of the existing framework 1.2 Goals 1.3 Benefits
2. *The new framework *2.1 Overview 2.2 Advantages
3. *New features *3.1 django-secure 3.2 django-update
4. *Schedule and milestones*
5. *Who am I?*

*1. Abstract*

*1.1 Drawbacks of the existing framework*

Django currently has a validation framework, but there are a lot of 
problems with it. First of all, it is monolithic and developers cannot 
write custom validation (see [#16905]) or modify the existing functionality 
(see [#12674]); validation lives in a few functions like 
django.core.management.validation.get_validation_errors [1] or 
django.contrib.admin.validation.validate [2]. The validation functionality 
is not separated from other stuff like printing found errors during 
validating models in get_validation_errors or registering models in admin 
app [3] (see [#8579]); it is sometimes done during first call to an 
important method, i. e. CurrentSiteManager [4] is validated in its 
get_queryset [5] method.

[#12674] https://code.djangoproject.com/ticket/12674
[#16905] https://code.djangoproject.com/ticket/16905
[1] 
https://github.com/django/django/blob/master/django/core/management/validation.py#L22
[2] 
https://github.com/django/django/blob/master/django/contrib/admin/validation.py#L14
[3] 
https://github.com/django/django/blob/master/django/contrib/admin/sites.py#L52
[#8579] https://code.djangoproject.com/ticket/8579
[4] 
https://github.com/django/django/blob/master/django/contrib/sites/managers.py#L5
[5] 
https://github.com/django/django/blob/master/django/contrib/sites/managers.py#L38

There are few tests of the validation framework and it is not easily 
testable because validation functions return concatenated error messages 
instead of list of errors (see 
django.tests.invalid_models.invalid_models.models [6]). It also lacks some 
features like warnings (see [#19126]). Due to this disadvantages lots of 
apps do not have any validation, i. e. they do not check inter-app 
dependencies.

[6] 
https://github.com/django/django/blob/master/tests/invalid_models/invalid_models/models.py#L366
[#19126] https://code.djangoproject.com/ticket/19126

*1.2 Goals*

This proposal is about revamping current validation framework. First of 
all, we need to write more tests and rewrite existing ones. Then we need an 
consistent API of validating different kinds of objects like models, 
fields, managers or whole apps so it will be easy to add new kind of 
object. Validation functionality should be separated from other stuff and 
it should minimize dependencies. We should allow developers to add 
validation to their apps and any other kind of objects, so custom 
validation is a must. We will not break backward compatibility.

This proposal is not only about refactoring but also introducing new 
features. Introducing warnings is first feature that allows us to add 
security warnings based on django-secure [7] app. The second main feature 
is making switching to newer version of Django easier by developing 
django-update app which should inspect settings as well as models and 
predict and warn about some problems.

[7] https://github.com/carljm/django-secure

*1.3 Benefits*

There are a lot of benefits. Cleaning code, removing unwanted dependencies 
and adding more tests are the most obvious ones. We will also benefit from 
long term solution which will be easy to maintain since it is extendable. 
Switching Django version will be piece of cake. We will improve security of 
Django projects thanks to security warnings. This also implies that Django 
will be considered as a safe and secure framework. Better opinion is always 
desired.

*2. The new framework*

*2.1 Overview*

The API is based on Honza Kral idea from his patch [8]. An developer can 
add new validation functionality by writing a callable piece of code. It 
will be automatically called during validating whole project (triggered by 
python 
manage.py validate) and it must fulfill the following contract: it has no 
arguments and returns a list of warnings and errors or yields each of them.

[8] https://github.com/HonzaKral/django/compare/master...ticket-12674

The validated object may be a model, a manager, a field or an app. In case 
of a field or a manager, the callable piece of code is a method. In case of 
a model, it is a classmethod. In case of an app, we will put functions in 
validation.py file.

Let's see an example::

class FieldFile(File):
>
(lots of stuff)
>

> def validate_upload_to_attribute(self):
>
if not self.upload_to:
>
yield Error(obj=self, msg="required 'upload_to' attribute",
>
explanation="Django need to know the 

Re: The threat of the incompletely initialized django instance

[ptone]

On Monday, April 15, 2013 4:51:24 AM UTC-7, Pakal wrote:
>
> (my previous answer disappeared in googlemail, I hope that one will 
> survive the sending...)
>
> Thanks for the feedback,
>
> Preston, since ticket #3591 ticket and related discusions are partially 
> obsolete compared to your current works, may I just know if your current 
> evolution will automatically reproduce the auto init() of the devserver 
> (i.e loading models from each installed app) ? Because being able to use 
> the same several times, or to set its human name, are cool features, but 
> imo the most critical part at the moment is that difference between dev and 
> prod inits, which can bite hard the unwary djangoer.
>
>
The approach would be more along the lines of defining a place that is 
guaranteed to run at as distinct a time as possible in the startup process 
- rather than trying to guarantee that all code gets imported in some 
coherent way with the aim to trigger module level import code. The latter 
is what we want to move away from.

-Preston
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.