date:20160319

You're right. Assume I put the keyword arguments at the end, sorry - the
two positional arguments are the channel name and the consumer.

On Fri, Mar 18, 2016 at 12:21 PM, Ryan Hiebert  wrote:

>
> On Mar 18, 2016, at 9:58 AM, Andrew Godwin  wrote:
>
> routing = [
> route("http.request", ViewConsumer),
> route("websocket.connect", path="^chat/(?P[^/]+)/$",
> ChatConnect),
> route("sms.receive", sender="+44(?P[0-9]+)$",
> UkSmsConsumer),
> include(path="^notifications", "notification.routing.routing"),
> ]
>
>
> Something's up with this example, it has postional arguments after keyword
> arguments, which is invalid Python. Is there supposed to be a keyword used
> for the final parameters?
>
> --
> 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/68C930D0-1C2E-4CF4-B3B8-DA8450C468AB%40ryanhiebert.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/CAFwN1uo670c7SJ%3D9tiP6FBBxaR9jTduN6CiuQsK_5hpbsaQPkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bringing some popular must have django tools/packages under django org umbrella

2016-03-19 Thread Michal Petrucha

On Wed, Mar 16, 2016 at 04:06:32PM +0100, Raphaël Barrois wrote:
> Hello there,
> 
> I am not sure the tone of that discussion is suitable for that mailing-list ;)

I totally agree on this point. Let's try to keep it civil.

> Regarding the initial discussion, if I understand correctly, the idea would 
> be to find a way to prevent useful packages
> from turning into abandoned, unmaintained projects.
> 
> From my (personal) experience:
> - If someone is interested in taking over maintenance of an abandoned 
> project, the original author is often quite happy
>   to help
> - If the task seems too daunting to handle it single-handedly, you could try 
> to find a few other power-users of the
>   package who would be willing to help maintain it
> 
> In that second case, the benefit of a generic/umbrella organisation would be 
> to simplify the task of finding
> co-maintainers for a project.
> 
> I am not part of the Django team, but I don't see why the maintenance of 
> those extra projects would have to be handled
> by the Django team; a better start might be to approach the maintainers of a 
> few projects that matter to you and
> discuss the idea with them; if that works, you could, as a group, decide 
> whether you want that to happen within the
> Django org or within a different org.

Correct me if I'm wrong, but isn't this exactly what Jazzband
(https://jazzband.co/) is about? Coincidentally, currently it consists
mostly of Django projects.

Michal

-- 
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/20160316152414.GR25061%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: [GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

2016-03-19 Thread Collin Anderson

Hi Connor,

I personally usually avoid class based views whenever possible and stick to 
function based views whenever possible. Would these Conditions be usable 
within function based views too?

Thanks,
Collin


On Thursday, March 17, 2016 at 8:00:16 AM UTC-4, Connor Boyle wrote:
>
> My original inspiration actually was Django Rest Framework, but I wanted 
> to show that I had actually thought it out and that it is indeed possible 
> to implement in core Django (albeit not quite as cleanly as DRF does it). 
> I'll try to finish a more detailed write-up of how they compare, but in 
> short they are very similar. In terms of overall paradigm, the largest 
> difference is that DRF's "permissions" are designed exclusively for being 
> run given the request or the request and the result of get_object(). My 
> proposal, on the other hand, would allow conditions to be written that 
> don't require these arguments and in fact require other arguments, although 
> it does provide appropriate sub-classes for these extremely common usage 
> cases. This is enabled by one other key difference between the two: my 
> proposal's separation between the evaluate() layer–the one that's generally 
> overridden by the developer or by common usage sub-classes–and the run() 
> layer–which calls the evaluate() layer after picking which keyword 
> arguments it should pass to it.
>
> On Thursday, March 17, 2016 at 1:31:37 AM UTC+8, Ryan Hiebert wrote:
>>
>>
>> On Mar 16, 2016, at 11:55 AM, Connor Boyle  wrote:
>>
>> I'm hoping to add a feature that I've thought Django has needed for a 
>> long time, and thought that Google Summer of Code would be an excellent 
>> opportunity for it. Basically, it would be an API for defining 'Conditions' 
>> and applying them to Views. [snip]
>>
>> 1. How clear and convincing is the section describing what's wrong with 
>> the current solution ('The Problem(s)')? Any criticisms on that section 
>> would be very welcome.
>>
>>
>> It seems like a neat idea, and reasonably well thought out, though I 
>> don't have the standing needed to speak to its viability as a GSOC project 
>> or for inclusion in Django. I'd be interested to see a write-up comparing 
>> this with Django Rest Framework's Permissions, which seem pretty similar in 
>> concept. http://www.django-rest-framework.org/api-guide/permissions/
>>
>

-- 
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/2748d40d-ed70-48e0-a613-27d938a77fbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - March 19, 2016

2016-03-19 Thread Tim Graham

Triaged

---

https://code.djangoproject.com/ticket/26351 - Recommend enabling MySQL's
STRICT_TRANS_TABLES to prevent silent truncation (accepted)

https://code.djangoproject.com/ticket/26355 - Add support for PostgreSQL's
array_append to ArrayField (accepted)

https://code.djangoproject.com/ticket/26356 - Allow management commands to
require tagged checks (wontfix)

https://code.djangoproject.com/ticket/26365 - Add a system check to ensure
"string_if_invalid" is a string (accepted)

https://code.djangoproject.com/ticket/26362 - Manually changing the parent
of a child model is silently failing (accepted)

https://code.djangoproject.com/ticket/26366 - Implicitly save related
models as needed instead of raising "unsaved related objects error" on
Model.save() (wontfix)

https://code.djangoproject.com/ticket/26367 - Assess if FieldFile can work
with stdlib File instead of requiring Django's File (accepted)

https://code.djangoproject.com/ticket/26373 - Reverse lookup with subquery
with a ForeignKey with to_field set causes FieldError (accepted)

https://code.djangoproject.com/ticket/26380 - 'FileField' attribute has no
file associated with it (duplicate)

Authored

https://github.com/django/django/pull/6306 - Fixed #26265 -- Clarified
RadioSelect container's HTML id.

https://github.com/django/djangoproject.com/pull/646 - Added support for
gold/platinum members on fundraising page.

Reviewed/committed

https://github.com/django/django/pull/6293 - Fixed #26334 -- Removed
whitespace stripping from contrib.auth password fields.

https://github.com/django/django/pull/6278 - Fixed #25579 -- Fixed
ArrayField.get_db_prep_value() to allow complex types.

https://github.com/django/django/pull/6277 - Fixed #26158 -- Rewrote
http.parse_cookie() to better match browsers.

https://github.com/django/django/pull/6288 - Fixed #26297 -- Fixed
`collectstatic --clear` crash if storage doesn't implement path().

https://github.com/django/django/pull/6259 - Fixed #26306 -- Fixed memory
leak in cached template loader.

https://github.com/django/django/pull/5530 - Fixed #25658 -- Allowed
inspectdb to inspect a specific set of tables.

https://github.com/django/django/pull/6090 - Fixed #25232 -- Made
ModelBackend authentication backend reject inactive users

https://github.com/django/django/pull/6124 - Fixed #24987 -- Allowed
inactive users to login with the test client.

https://github.com/django/django/pull/6304 - Fixed #26373 -- Fixed reverse
lookup crash with a ForeignKey to_field in a subquery.

Reviews of core dev work

https://github.com/django/django/pull/6289 - Fixed #26157 #25321 -- Added
sql/params to extra context of schema logger.

--
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/4d6b3ccc-eb45-46ba-b3ca-f4bb972da73f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

I like most of it apart from the fact you can set a consumer to consume ANY
channel, which seems incredibly dangerous - when a channel is wrongly
consumed the only visible error is usually just a lack of response to the
end client, and no two channels have messages that are similar in any
useful way.

I think include should never need a channel, and route should always need
one - which means the router always knows that every entry has exactly one
channel defined that can be matched against.

Andrew

On Fri, Mar 18, 2016 at 5:43 PM, Vincent  wrote:

> Andrew,
>
> Ah, excellent. I just took a short break (too many LOC at work today), and
> while I was away I was thinking about all of this.
>
> Here's what I came up with:
>
> https://gist.github.com/orokusaki/17b4cf734b4d2f2af117
>
> On Friday, March 18, 2016 at 3:57:38 PM UTC-4, Andrew Godwin wrote:
>>
>>
>>
>> On Fri, Mar 18, 2016 at 4:40 PM, Vincent  wrote:
>>
>>> Hey Andrew,
>>>
>>> Thanks for looking through all that, and for the reply.
>>>
>>> I like the simplicity of your updated examples. I started to make a
>>> counter-example to suggest that `include` be inside of a `route` (
>>> https://gist.github.com/orokusaki/c0c934013ee7911071ef).
>>>
>>> But then, as I thought through this, I think I like your example almost*
>>> exactly like it is, but I'm afraid there might be a problem:
>>>
>>> Given your example, any message how would a 'websocket.connect' message
>>> at the path `notifications/foo/` be routed, giving this example:
>>>
>>> routing = [
>>> route("websocket.connect", ChatConnect),
>>> include(path="^notifications", "notification.routing.routing"),
>>> ]
>>>
>>> Given that the chat route is the first match, wouldn't the notifications
>>> route never be used? Would path need to be required, so that the matching
>>> would be similar to `urlpatterns`? Otherwise, we're allowing routing based
>>> on channel name or path again? Maybe I'm misunderstanding.
>>>
>>>
>> My idea there was that, like urlpatterns, it would go down the list in
>> order, so if you did it like this:
>>
>> routing = [
>> include("notification.routing.routing", path="^notifications"),
>> route("websocket.connect", ChatConnect),
>> ]
>>
>> Then it would check the include first, before hitting the catchall. This
>> is what you have to do with catchall URLs now, so I don't think it will be
>> too unusual.
>>
>> Andrew
>>
> --
> 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/9ce52a05-88d6-412f-9cfe-59c600c35df7%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/CAFwN1upU7HMCZ2r1Qsb8mm0QAQEwFXH3K5GS2tpnsu5a-0Rn4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

2016-03-19 Thread Tim Graham

I'm not sure whether or not to accept a related proposal to add a 
"formfield_defaults" keyword to model fields [0]. e.g.

link = models.OneToOneField(
...
formfield_defaults={
'widget': forms.RadioSelect,
}
)


It seems useful, but I'm not sure if it increases the coupling between 
model and forms in an undesirable way?

[0] https://code.djangoproject.com/ticket/26369

On Wednesday, March 9, 2016 at 1:43:16 PM UTC-5, Johannes Hoppe wrote:
>
> I got that, but you can't just make it your default widget, it will always 
> require more information. And I don't really like "defaults", again pep20.
>
> I currently don't have any need for action, therefore I won't do anything. 
> If you want to make a draft on how to refactor it, I'm happy to review it.
>
>> On Mar 9 2016, at 6:49 pm, James Pic  
>> wrote: 
>>
>> I just meant that currently, if a user wants to make Select2 the
>> default widget for a model field, it is necessary to subclass the
>> modelfield class and override the model field's formfield() method
>> just to change the default widget it uses, sorry if it wasn't clear !
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/zG-JvS_opi4/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/CALC3Kaet9-Fy7BF64Fgtjh3MBz9EA7DR67FUkzhdS2HGg4821g%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/02213ab6-58fc-4abd-8f82-e147ff059d72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

Yes, definitely! That was something I had in mind coming up with the 
concept. The "Conditions" themselves are written with no knowledge of and 
have no relation to class-based views, they simply give a pass or a fail 
given certain conditions.

On Friday, March 18, 2016 at 10:56:46 PM UTC+8, Collin Anderson wrote:
>
> Hi Connor,
>
> I personally usually avoid class based views whenever possible and stick 
> to function based views whenever possible. Would these Conditions be usable 
> within function based views too?
>
> Thanks,
> Collin
>
>
> On Thursday, March 17, 2016 at 8:00:16 AM UTC-4, Connor Boyle wrote:
>>
>> My original inspiration actually was Django Rest Framework, but I wanted 
>> to show that I had actually thought it out and that it is indeed possible 
>> to implement in core Django (albeit not quite as cleanly as DRF does it). 
>> I'll try to finish a more detailed write-up of how they compare, but in 
>> short they are very similar. In terms of overall paradigm, the largest 
>> difference is that DRF's "permissions" are designed exclusively for being 
>> run given the request or the request and the result of get_object(). My 
>> proposal, on the other hand, would allow conditions to be written that 
>> don't require these arguments and in fact require other arguments, although 
>> it does provide appropriate sub-classes for these extremely common usage 
>> cases. This is enabled by one other key difference between the two: my 
>> proposal's separation between the evaluate() layer–the one that's generally 
>> overridden by the developer or by common usage sub-classes–and the run() 
>> layer–which calls the evaluate() layer after picking which keyword 
>> arguments it should pass to it.
>>
>> On Thursday, March 17, 2016 at 1:31:37 AM UTC+8, Ryan Hiebert wrote:
>>>
>>>
>>> On Mar 16, 2016, at 11:55 AM, Connor Boyle  
>>> wrote:
>>>
>>> I'm hoping to add a feature that I've thought Django has needed for a 
>>> long time, and thought that Google Summer of Code would be an excellent 
>>> opportunity for it. Basically, it would be an API for defining 'Conditions' 
>>> and applying them to Views. [snip]
>>>
>>> 1. How clear and convincing is the section describing what's wrong with 
>>> the current solution ('The Problem(s)')? Any criticisms on that section 
>>> would be very welcome.
>>>
>>>
>>> It seems like a neat idea, and reasonably well thought out, though I 
>>> don't have the standing needed to speak to its viability as a GSOC project 
>>> or for inclusion in Django. I'd be interested to see a write-up comparing 
>>> this with Django Rest Framework's Permissions, which seem pretty similar in 
>>> concept. http://www.django-rest-framework.org/api-guide/permissions/
>>>
>>

-- 
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/f56e5ac5-4159-4d09-939f-7e7e2adfb69e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

Yes, my intent is that "path" is just a stand-in for "any string key in a
message", thus you could route other ways (for example, `method` in
http.request, though that's probably not super useful inside Django).

Andrew

On Sat, Mar 19, 2016 at 1:40 PM, Vincent  wrote:

> Andrew,
>
> Thanks for the explanation.
>
> (re: including based only on path, routing based on channel (and
> optionally path?)), I really really like that simplicity, the more I think
> about it.
>
> Expanding on that to include your prior examples, I'm assuming `path` is
> just incidental for http / websocket, and that other kwargs would be
> relevant for `include`:
>
> routing = [
> # Catches any US phone number and delegates to myapp.us.routing.routing
> include('my_us_app.routing', sender=r'\+1(?P[0-9]+)$'),
>
> # Catches any UK phone number and routes to UkSmsConsumer
> route('sms.receive', sender=r'\+44(?P[0-9]+)$',
> UkSmsConsumer),
> ]
>
> Is that right?
>
> On Friday, March 18, 2016 at 5:18:51 PM UTC-4, Andrew Godwin wrote:
>>
>> I like most of it apart from the fact you can set a consumer to consume
>> ANY channel, which seems incredibly dangerous - when a channel is wrongly
>> consumed the only visible error is usually just a lack of response to the
>> end client, and no two channels have messages that are similar in any
>> useful way.
>>
>> I think include should never need a channel, and route should always need
>> one - which means the router always knows that every entry has exactly one
>> channel defined that can be matched against.
>>
>> Andrew
>>
>> On Fri, Mar 18, 2016 at 5:43 PM, Vincent  wrote:
>>
>>> Andrew,
>>>
>>> Ah, excellent. I just took a short break (too many LOC at work today),
>>> and while I was away I was thinking about all of this.
>>>
>>> Here's what I came up with:
>>>
>>> https://gist.github.com/orokusaki/17b4cf734b4d2f2af117
>>>
>>> On Friday, March 18, 2016 at 3:57:38 PM UTC-4, Andrew Godwin wrote:



 On Fri, Mar 18, 2016 at 4:40 PM, Vincent  wrote:

> Hey Andrew,
>
> Thanks for looking through all that, and for the reply.
>
> I like the simplicity of your updated examples. I started to make a
> counter-example to suggest that `include` be inside of a `route` (
> https://gist.github.com/orokusaki/c0c934013ee7911071ef).
>
> But then, as I thought through this, I think I like your example
> almost* exactly like it is, but I'm afraid there might be a problem:
>
> Given your example, any message how would a 'websocket.connect'
> message at the path `notifications/foo/` be routed, giving this example:
>
> routing = [
> route("websocket.connect", ChatConnect),
> include(path="^notifications", "notification.routing.routing"),
> ]
>
> Given that the chat route is the first match, wouldn't the
> notifications route never be used? Would path need to be required, so that
> the matching would be similar to `urlpatterns`? Otherwise, we're allowing
> routing based on channel name or path again? Maybe I'm misunderstanding.
>
>
 My idea there was that, like urlpatterns, it would go down the list in
 order, so if you did it like this:

 routing = [
 include("notification.routing.routing", path="^notifications"),
 route("websocket.connect", ChatConnect),
 ]

 Then it would check the include first, before hitting the catchall.
 This is what you have to do with catchall URLs now, so I don't think it
 will be too unusual.

 Andrew

>>> --
>>> 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/9ce52a05-88d6-412f-9cfe-59c600c35df7%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
>

Re: Make STATIC_URL context variable aware of backing storage with staticfiles

2016-03-19 Thread Florian Apolloner

On Saturday, March 19, 2016 at 7:01:28 PM UTC+1, Daniel R wrote:
>
> But given the wide use of {{STATIC_URL}} this may be an easy and 
> worthwhile fix instead of asking users to change template references.
>

Wide? Not sure what your definition of wide is, but I suspect that the tag 
has way higher usage, especially since it is the only way if you want to 
work it with the storage backends.

> What do you think ? 
>

Nothing, cause it is not as simple as you suggest, storage backends in 
general also change the name of the file to include a hash of the contents 
etc… Your only sensible option is to switch to the tag. Fwiw, writing a 
simple script which performs replacement in every template should be simple 
enough…

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/7457a42c-b166-4ea4-bc1e-cda1477a81ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bringing some popular must have django tools/packages under django org umbrella

On Wed, Mar 16, 2016 at 3:22 PM, Matías Iturburu  wrote:
> Even if I submit a patch I wouldn't be able to:
> - Merge it into mainline.
> - Upload the patched version to pypi.
>
> So it's a no-starter,
> I can't rely on my fork, not for production, as I
> should guarantee that the package it's, at least, as tested as mainline,
> which usually involves non-trivial infrastructure.

If I understand correctly, you need a patch, but you don't want to do
it, because you can't have it released right away.

Your work is to have a feature in a project, you want to use an app,
but you don't want to contribute to it. If I understand correctly, you
want volunteers to do the work for you so that you get your project
done and perhaps even get paid, and not give anything in return.

Good patches are quickly merged. If it has tests, and good code
coverage, and supports new versions of Python, I can tell you it's not
going to take long before your patch is merged in most cases.

Otherwise, yeah, just publish your fork on PyPi until it's merged
upstream. I don't see what's the problem here. We've had the case in
django-cities-light were a user implemented Region support, published
it in django-cities-reducedfat or something (lol), and then
contributed upstream, and then we released the contribution in
django-cities-light. What's the issue here ?

>>
>> I know the first portings are hard but once you've ported a dozen it
>> becomes piece of cake so don't be afraid of trying ! And please contribute
>> to the apps !!
>>
>> I know some people who only open issues and never submit a patch on
>> github, isn't that super annoying?
>
> Really? you go around asking users to do the work of maintainers?

I don't understand, what do you mean work ? Are you paying the
maintainers to maintain their projects ? Are you talking about
dual-licensed projects like django-suit where you payed an Enterprise
license for ?

Well what do you prefer, that maintainers shut down a project because
they don't have time or motivation to keep on, or do you prefer that
the project lives on with community support ?

If I understand your logic correctly, you should re-implement the
features you were using from an app in your own project to drop the
dependency on the app that you consider un-maintained. Either way, you
end up doing your job, but if you contribute then it's for everybody,
not just your project.

Seems like "Open Source" doesn't wrok the same in your world and in mine :)

Perhaps if you were maintaining Open Source apps you'd understand. I
don't know if you use any things like torrents, but do you know what
the "leecher" concept is like ? It's when a user downloads and then
doesn't share.

I don't think I have anything to add here, I'm sure more experienced
hackers will find better phrasings than me for this. I may sound
harsh, but really I'm not, I'm just trying to understand how your
logic works and so far it seems broken for me so I'd really like to
understand.

Also, about django-endless-pagination, I tried it once, but then
decided to go on with my own 5 sloc of JS implemantion of endless
pagination, using Django's normal pagination on the python side, so
I'd like to be convinced that it's really necessary in a project ! But
that I guess is another topic.

Best ;)

James

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

Re: Status of DEP 0005: Improved middleware?

2016-03-19 Thread Florian Apolloner

The current PR is here: https://github.com/django/django/pull/5949 -- Now 
that the general idea is clear, I think I will push it as branch to the 
main Django repo, so others can help working on it. There is still quite a 
bit to do, but the general functionality is working as intended.

Cheers,
Florian

On Wednesday, March 16, 2016 at 4:34:15 PM UTC+1, guettli wrote:
>
> Thank you. I am happy that this gets solved.
>
> Am Dienstag, 15. März 2016 15:54:26 UTC+1 schrieb Tim Graham:
>>
>> Here's the mailing list thread: 
>> https://groups.google.com/d/topic/django-developers/8LMJ44KAxWI/discussion
>>
>> I think mostly the implementation just needs to be completed.
>>
>> On Tuesday, March 15, 2016 at 10:32:15 AM UTC-4, guettli wrote:
>>>
>>> I like the improved middleware proposal: 
>>> https://github.com/django/deps/blob/master/draft/0005-improved-middleware.rst
>>>
>>> What is the status of it?
>>>
>>> Is there an agreement under the django-core developers that the proposal 
>>> is the right direction?
>>>
>>> Regards,
>>>   Thomas Güttler
>>>
>>

-- 
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/357a2620-c85a-4024-9343-fe1d54a203a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Make STATIC_URL context variable aware of backing storage with staticfiles

2016-03-19 Thread Daniel R

I've always used the STATIC_URL context processor variable in templates and 
didn't have trouble with it up until a few days ago when a customer 
required to use the STATICFILES_STORAGE.

I then realized I would need to change all the {{STATIC_URL}} template 
references to use a {% static %} tag via {% load static from staticfiles 
%}, which just seemed overwhelming, so I just tweaked 
django.template.context_processors.static to make it staticfiles aware.  

Given the prevelance of templates that use {{STATIC_URL}} and now the 
possibility of changing storage, I thought I'd suggest this as a possible 
new fix/feature. Here's another post which addreses the same 
problem 
http://staticfiles.productiondjango.com/blog/stop-using-static-url-in-templates/
 
but simply says to use {% load static from staticfiles %} and never use 
{{STATIC_URL}}. But given the wide use of {{STATIC_URL}} this may be an 
easy and worthwhile fix instead of asking users to change template 
references.

What do you think ? 

Current django.template.context_processors.static is pretty basic:

def static(request):
"""
Adds static-related context variables to the context.
"""
return {'STATIC_URL': settings.STATIC_URL}



It would change to something like 

def static(request):
"""
Adds static-related context variables to the context.
"""
if 'django.contrib.staticfiles' in settings.INSTALLED_APPS:
   from django.contrib.staticfiles.storage import staticfiles_storage
   return {'STATIC_URL':staticfiles_storage.url }
else:
   return {'STATIC_URL': settings.STATIC_URL}



-- 
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/cb536a08-2ebf-4041-89d6-5e54aca7aef0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

Andrew,

Ah, excellent. I just took a short break (too many LOC at work today), and 
while I was away I was thinking about all of this.

Here's what I came up with:

https://gist.github.com/orokusaki/17b4cf734b4d2f2af117

On Friday, March 18, 2016 at 3:57:38 PM UTC-4, Andrew Godwin wrote:
>
>
>
> On Fri, Mar 18, 2016 at 4:40 PM, Vincent  > wrote:
>
>> Hey Andrew,
>>
>> Thanks for looking through all that, and for the reply.
>>
>> I like the simplicity of your updated examples. I started to make a 
>> counter-example to suggest that `include` be inside of a `route` (
>> https://gist.github.com/orokusaki/c0c934013ee7911071ef).
>>
>> But then, as I thought through this, I think I like your example almost* 
>> exactly like it is, but I'm afraid there might be a problem:
>>
>> Given your example, any message how would a 'websocket.connect' message 
>> at the path `notifications/foo/` be routed, giving this example:
>>
>> routing = [
>> route("websocket.connect", ChatConnect),
>> include(path="^notifications", "notification.routing.routing"),
>> ]
>>
>> Given that the chat route is the first match, wouldn't the notifications 
>> route never be used? Would path need to be required, so that the matching 
>> would be similar to `urlpatterns`? Otherwise, we're allowing routing based 
>> on channel name or path again? Maybe I'm misunderstanding.
>>
>>
> My idea there was that, like urlpatterns, it would go down the list in 
> order, so if you did it like this: 
>
> routing = [
> include("notification.routing.routing", path="^notifications"),
> route("websocket.connect", ChatConnect),
> ]
>
> Then it would check the include first, before hitting the catchall. This 
> is what you have to do with catchall URLs now, so I don't think it will be 
> too unusual.
>
> Andrew
>

-- 
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/9ce52a05-88d6-412f-9cfe-59c600c35df7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ GSOC 2016 ] providing standard interface for NoSQL databases

2016-03-19 Thread girish ramnani

In the beginning I thought about making an api which supports column 
databases such as cassendra but would mean that i would need to first find 
commonalities between all 3 ( column , document and relational ) but such 
commonalities would be lesser and so finally i would require to create a 
separate api instead of trying to provide it with db.Model.

So i will be target only document based databases like mongo , rethink etc.

There is an opinion I seek from the community.

1 ) Providing a separate Model written specifically for document database 
would provide easier addition of new features related to real time 
capabilities which could be used after ASGI gets merged. Also a developer 
usually knows before writing any code which type of database (relational or 
non-relational ) so in my opinion there wouldn't be developers who would 
use sqlite in dev mode and then change it to mongo in production. So would 
it be better to provide a separate Model for document databases ?

2 ) On the other hand , using the db.Model will be easier to use as the api 
is already familiar with the developers but using the same api suggests a 
certain level of similarity between databases which cant be seen in case of 
relational and document databases. 

So would the community be open to adding a seperate Model class eg. 
DocumentModel or Collection .

There are alot of problems which are to be address ( some mentioned by Anssi 
Kääriäinen ).

The multiple database support,Forms,migrations,Meta,django admin , django 
auth etc. I would try to address the problems in my proposal as in-depth as 
possible. 

On Wednesday, March 16, 2016 at 3:20:25 AM UTC+5:30, Curtis Maloney wrote:
>
> It sounds like by "NoSQL DBS" you mean specifically "Document store 
> DBMS".  Is this correct? 
>
> (I'm sure most people know my rant about how "NoSQL" is a misnomer, and 
> it's really "Non-relational" that people mean - it's not SQL per se 
> they're avoiding, it's the relational model) 
>
> The NoSQL/Non-rel name is really too vague, as it covers "anything 
> that's not SQL / Relational"... which can cover key/value, document, 
> graph, log, and even filesystem or email, when it comes down to it. 
>
> I think it will help if you clarify what model you _do_ target, not 
> which you do _not_. 
>
> All that said/vented, I agree it would be nice to have a common 
> abstraction layer atop various document stores.  The trick now will be 
> finding sufficient commonalities. 
>
> I feel that the ORM's relation-span/transforms/lookups syntax would be 
> equally viable on nested documents. 
>
> One of the benefits of an abstraction layer is allowing other tools to 
> generically interact with these new objects.  What plans do you have for 
> how to support non-flat documents in, for instance, Forms? 
>
>
> -- 
> Curtis 
>
> On 16/03/16 05:29, girish ramnani wrote: 
> > 
> > Hello, 
> > 
> > I would like to propose providing a standard interface for NoSQL 
> > databases . Some the points to consider are: 
> > 
> >  1. The /Fields /which are used to define the schema of the sql 
> > databases can also be used to provide in No sql databases. 
> >  2. In NoSQL dbs ,developers usually store data in denormalized form. so 
> > in two related collections a meta tag /denormal = True /can be 
> > provided. Which would make that collection a child of the other 
> > model ( related ). In normal scenario the collections will be 
> > connected using _id used as a foreign key. 
> >  3. providing contrib.mongo with Field such as GridFSField for providing 
> > support for GridFS 
> >  4. considering the database transaction transaction blocking ( PyMongo 
> > provides blocking api for mongo ) 
> >  5. creating Mixins such as /FlexibleMixin /which would allow Models to 
> > have dynamic fields. i.e directly insert fields which are not listed 
> > in the Model schema. 
> > 
> > 
> > there are lot more things (Migrations, settings etc) to consider but 
> > before that needed to know that I am going in the right direction or 
> > not?. Please suggest. 
> > 
> > -- 
> > 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/b2477318-9252-4241-a9fe-0972acb1b1cf%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/django-developers/b2477318-9252-4241-a9fe-0972acb1b1cf%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
> > For more options, visit

Re: [GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

2016-03-19 Thread Ryan Hiebert


> On Mar 16, 2016, at 11:55 AM, Connor Boyle  wrote:
> 
> I'm hoping to add a feature that I've thought Django has needed for a long 
> time, and thought that Google Summer of Code would be an excellent 
> opportunity for it. Basically, it would be an API for defining 'Conditions' 
> and applying them to Views. [snip]
> 
> 1. How clear and convincing is the section describing what's wrong with the 
> current solution ('The Problem(s)')? Any criticisms on that section would be 
> very welcome.

It seems like a neat idea, and reasonably well thought out, though I don't have 
the standing needed to speak to its viability as a GSOC project or for 
inclusion in Django. I'd be interested to see a write-up comparing this with 
Django Rest Framework's Permissions, which seem pretty similar in concept. 
http://www.django-rest-framework.org/api-guide/permissions/ 


-- 
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/046E080A-B21F-437A-AAD0-2151CF61CCE4%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: change to the way list_editable form data is submitted in the admin

2016-03-19 Thread John C

Thanks. #11652 is a good description of the same problem in the context of 
the "change" page. I think that, in practice, it is more of a problem with 
a list_editable, since you're updating many records at once. This makes a 
"collision" with some other part of the system more likely.

I think the approach outlined in #16549, which requires persisting a 
version number, would suffice but is not really necessary. I can understand 
wanting to make the solution applicable more widely than just one 
particular admin feature; however, the best solution depends on the 
context. In the case of #11652, optimistic locking is a good fit, because 
we can't assume the granularity of the different fields on the model. 
Whereas with list_editable, it's a bunch of records of the same type. It is 
quite safe to assume that we can consider the records that were updated by 
the user, compared to the values originally displayed, and do all these 
changes independently of one another. From this point of view, it is 
actually an optimization, to skip the update when there is no change.

-John

On Wednesday, March 16, 2016 at 8:21:40 PM UTC-5, Josh Smeaton wrote:
>
> I know this particular case has been discussed before. Here are two 
> related tickets (I think there's a better canonical ticket but I can't find 
> it just now): https://code.djangoproject.com/ticket/11652 and 
> https://code.djangoproject.com/ticket/16549
>
> I haven't done the required reading recently, so I can't comment on 
> whether or not your idea could be accepted. But hopefully those tickets 
> should provide a bit more information for investigation puproses.
>
>
>
> On Thursday, 17 March 2016 11:37:06 UTC+11, John C wrote:
>>
>> Hey,
>>
>> For the past five years, I've been using Django to manage a database of 
>> online applications. I absolutely love it! Makes my job so much easier.
>>
>> In general, any problems I run into, there's usually an easy workaround. 
>> But I wonder if that's even feasible in this case. Anyway, here's the 
>> problem: in managing submissions we make a lot of use of the list_editable 
>> attribute of ModelAdmin, particularly for status columns. It's extremely 
>> handy to be able to load up a list, filter it, and then make status changes 
>> to selected records all in one go.
>>
>> However, there are times when these status columns are also changing on 
>> their own, due to what's happening on the front end. I have to be very 
>> careful to ensure that this doesn't happen in between when I load an admin 
>> list and when I click "Save." If so, then I may end up overwriting the 
>> newly changed data, back to what it was when the list was loaded in my 
>> browser. This is because all rows are always saved, based on the data in 
>> the form inputs from the list.
>>
>> I propose that a copy of the list_editable values be sent along as a 
>> hidden form element (or, alternatively, that Javascript be used to detect 
>> values changed in response to user input). That way, in the admin form 
>> handler, only rows that have been intended to be changed would be updated 
>> to submitted values.
>>
>> It adds some complexity, sure, but are there any disadvantages I haven't 
>> thought of? From my perspective, it would solve a rather frustrating 
>> problem.
>>
>> Thanks,
>> John Cronan
>>
>>

-- 
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/1f970804-7b49-44da-916f-21270e4a3cac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

Andrew,

Thanks for the explanation.

(re: including based only on path, routing based on channel (and optionally 
path?)), I really really like that simplicity, the more I think about it.

Expanding on that to include your prior examples, I'm assuming `path` is 
just incidental for http / websocket, and that other kwargs would be 
relevant for `include`:

routing = [
# Catches any US phone number and delegates to myapp.us.routing.routing
include('my_us_app.routing', sender=r'\+1(?P[0-9]+)$'),

# Catches any UK phone number and routes to UkSmsConsumer
route('sms.receive', sender=r'\+44(?P[0-9]+)$', 
UkSmsConsumer),
]

Is that right?

On Friday, March 18, 2016 at 5:18:51 PM UTC-4, Andrew Godwin wrote:
>
> I like most of it apart from the fact you can set a consumer to consume 
> ANY channel, which seems incredibly dangerous - when a channel is wrongly 
> consumed the only visible error is usually just a lack of response to the 
> end client, and no two channels have messages that are similar in any 
> useful way.
>
> I think include should never need a channel, and route should always need 
> one - which means the router always knows that every entry has exactly one 
> channel defined that can be matched against.
>
> Andrew
>
> On Fri, Mar 18, 2016 at 5:43 PM, Vincent  > wrote:
>
>> Andrew,
>>
>> Ah, excellent. I just took a short break (too many LOC at work today), 
>> and while I was away I was thinking about all of this.
>>
>> Here's what I came up with:
>>
>> https://gist.github.com/orokusaki/17b4cf734b4d2f2af117
>>
>> On Friday, March 18, 2016 at 3:57:38 PM UTC-4, Andrew Godwin wrote:
>>>
>>>
>>>
>>> On Fri, Mar 18, 2016 at 4:40 PM, Vincent  wrote:
>>>
 Hey Andrew,

 Thanks for looking through all that, and for the reply.

 I like the simplicity of your updated examples. I started to make a 
 counter-example to suggest that `include` be inside of a `route` (
 https://gist.github.com/orokusaki/c0c934013ee7911071ef).

 But then, as I thought through this, I think I like your example 
 almost* exactly like it is, but I'm afraid there might be a problem:

 Given your example, any message how would a 'websocket.connect' message 
 at the path `notifications/foo/` be routed, giving this example:

 routing = [
 route("websocket.connect", ChatConnect),
 include(path="^notifications", "notification.routing.routing"),
 ]

 Given that the chat route is the first match, wouldn't the 
 notifications route never be used? Would path need to be required, so that 
 the matching would be similar to `urlpatterns`? Otherwise, we're allowing 
 routing based on channel name or path again? Maybe I'm misunderstanding.


>>> My idea there was that, like urlpatterns, it would go down the list in 
>>> order, so if you did it like this: 
>>>
>>> routing = [
>>> include("notification.routing.routing", path="^notifications"),
>>> route("websocket.connect", ChatConnect),
>>> ]
>>>
>>> Then it would check the include first, before hitting the catchall. This 
>>> is what you have to do with catchall URLs now, so I don't think it will be 
>>> too unusual.
>>>
>>> Andrew
>>>
>> -- 
>> 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/9ce52a05-88d6-412f-9cfe-59c600c35df7%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/67476f8c-6cce-428d-93bd-562ffaabe2ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bringing some popular must have django tools/packages under django org umbrella

2016-03-19 Thread Raphaël Barrois

On Wed, 16 Mar 2016 15:39:40 +0100
James Pic  wrote:

> On Wed, Mar 16, 2016 at 3:22 PM, Matías Iturburu  wrote:
> > Even if I submit a patch I wouldn't be able to:
> > - Merge it into mainline.
> > - Upload the patched version to pypi.
> >
> > So it's a no-starter,
> > I can't rely on my fork, not for production, as I
> > should guarantee that the package it's, at least, as tested as mainline,
> > which usually involves non-trivial infrastructure.  
> 
> If I understand correctly, you need a patch, but you don't want to do
> it, because you can't have it released right away.
> 
> Your work is to have a feature in a project, you want to use an app,
> but you don't want to contribute to it. If I understand correctly, you
> want volunteers to do the work for you so that you get your project
> done and perhaps even get paid, and not give anything in return.
> 
> Good patches are quickly merged. If it has tests, and good code
> coverage, and supports new versions of Python, I can tell you it's not
> going to take long before your patch is merged in most cases.
> 
> Otherwise, yeah, just publish your fork on PyPi until it's merged
> upstream. I don't see what's the problem here. We've had the case in
> django-cities-light were a user implemented Region support, published
> it in django-cities-reducedfat or something (lol), and then
> contributed upstream, and then we released the contribution in
> django-cities-light. What's the issue here ?
> 
> >>
> >> I know the first portings are hard but once you've ported a dozen it
> >> becomes piece of cake so don't be afraid of trying ! And please contribute
> >> to the apps !!
> >>
> >> I know some people who only open issues and never submit a patch on
> >> github, isn't that super annoying?  
> >
> > Really? you go around asking users to do the work of maintainers?  
> 
> I don't understand, what do you mean work ? Are you paying the
> maintainers to maintain their projects ? Are you talking about
> dual-licensed projects like django-suit where you payed an Enterprise
> license for ?
> 
> Well what do you prefer, that maintainers shut down a project because
> they don't have time or motivation to keep on, or do you prefer that
> the project lives on with community support ?
> 
> If I understand your logic correctly, you should re-implement the
> features you were using from an app in your own project to drop the
> dependency on the app that you consider un-maintained. Either way, you
> end up doing your job, but if you contribute then it's for everybody,
> not just your project.
> 
> Seems like "Open Source" doesn't wrok the same in your world and in mine :)
> 
> Perhaps if you were maintaining Open Source apps you'd understand. I
> don't know if you use any things like torrents, but do you know what
> the "leecher" concept is like ? It's when a user downloads and then
> doesn't share.
> 
> I don't think I have anything to add here, I'm sure more experienced
> hackers will find better phrasings than me for this. I may sound
> harsh, but really I'm not, I'm just trying to understand how your
> logic works and so far it seems broken for me so I'd really like to
> understand.
> 
> Also, about django-endless-pagination, I tried it once, but then
> decided to go on with my own 5 sloc of JS implemantion of endless
> pagination, using Django's normal pagination on the python side, so
> I'd like to be convinced that it's really necessary in a project ! But
> that I guess is another topic.
> 
> Best ;)
> 
> James
> 


Hello there,

I am not sure the tone of that discussion is suitable for that mailing-list ;)


Regarding the initial discussion, if I understand correctly, the idea would be 
to find a way to prevent useful packages
from turning into abandoned, unmaintained projects.

>From my (personal) experience:
- If someone is interested in taking over maintenance of an abandoned project, 
the original author is often quite happy
  to help
- If the task seems too daunting to handle it single-handedly, you could try to 
find a few other power-users of the
  package who would be willing to help maintain it

In that second case, the benefit of a generic/umbrella organisation would be to 
simplify the task of finding
co-maintainers for a project.

I am not part of the Django team, but I don't see why the maintenance of those 
extra projects would have to be handled
by the Django team; a better start might be to approach the maintainers of a 
few projects that matter to you and
discuss the idea with them; if that works, you could, as a group, decide 
whether you want that to happen within the
Django org or within a different org.


-- 
Raphaël

-- 
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,

Re: [GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

I'm still working on fleshing out how specifically to add them into 
function-based views–what code the API should provide to automate or 
semi-automate the auth-related functionality once a Condition has failed 
(redirect to login, etc.). I'll get that in my proposal ASAP, but if you 
have any particular suggestions or (more likely) warnings, I'd really 
appreciate it.

On Friday, March 18, 2016 at 11:01:27 PM UTC+8, Connor Boyle wrote:
>
> Yes, definitely! That was something I had in mind coming up with the 
> concept. The "Conditions" themselves are written with no knowledge of and 
> have no relation to class-based views, they simply give a pass or a fail 
> given certain conditions.
>
> On Friday, March 18, 2016 at 10:56:46 PM UTC+8, Collin Anderson wrote:
>>
>> Hi Connor,
>>
>> I personally usually avoid class based views whenever possible and stick 
>> to function based views whenever possible. Would these Conditions be usable 
>> within function based views too?
>>
>> Thanks,
>> Collin
>>
>>
>> On Thursday, March 17, 2016 at 8:00:16 AM UTC-4, Connor Boyle wrote:
>>>
>>> My original inspiration actually was Django Rest Framework, but I wanted 
>>> to show that I had actually thought it out and that it is indeed possible 
>>> to implement in core Django (albeit not quite as cleanly as DRF does it). 
>>> I'll try to finish a more detailed write-up of how they compare, but in 
>>> short they are very similar. In terms of overall paradigm, the largest 
>>> difference is that DRF's "permissions" are designed exclusively for being 
>>> run given the request or the request and the result of get_object(). My 
>>> proposal, on the other hand, would allow conditions to be written that 
>>> don't require these arguments and in fact require other arguments, although 
>>> it does provide appropriate sub-classes for these extremely common usage 
>>> cases. This is enabled by one other key difference between the two: my 
>>> proposal's separation between the evaluate() layer–the one that's generally 
>>> overridden by the developer or by common usage sub-classes–and the run() 
>>> layer–which calls the evaluate() layer after picking which keyword 
>>> arguments it should pass to it.
>>>
>>> On Thursday, March 17, 2016 at 1:31:37 AM UTC+8, Ryan Hiebert wrote:

 On Mar 16, 2016, at 11:55 AM, Connor Boyle  
 wrote:

 I'm hoping to add a feature that I've thought Django has needed for a 
 long time, and thought that Google Summer of Code would be an excellent 
 opportunity for it. Basically, it would be an API for defining 
 'Conditions' 
 and applying them to Views. [snip]

 1. How clear and convincing is the section describing what's wrong with 
 the current solution ('The Problem(s)')? Any criticisms on that section 
 would be very welcome.

 It seems like a neat idea, and reasonably well thought out, though I 
 don't have the standing needed to speak to its viability as a GSOC project 
 or for inclusion in Django. I'd be interested to see a write-up comparing 
 this with Django Rest Framework's Permissions, which seem pretty similar 
 in 
 concept. http://www.django-rest-framework.org/api-guide/permissions/

>>>

-- 
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/2df0e9da-3629-414f-a781-372acb179433%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Working on a profiling/benchmark tool for the django template language. Looking for feedback on my work so far.

2016-03-19 Thread Quentin Fulsher

Hi all, I talked with FunkyBob on IRC a few weeks ago and told him I was
interested in optimizing the template language. One of the suggestions he
made was to make a profiling/benchmarking framework to test changes. While
I wouldn't call it a framework yet I have a script set up to run the django
template language on a few simple templates and profile individual
functions. Right now I have the render(), context(), and Template() methods
added but definitely plan on adding more. You can read more on the github
page to learn the exact commands but the script can run individual test
cases and print out a pstats log. By specifying -o you can also create a
callgraph.

At this point I'm looking for ways to improve. Right now the script
implementation is kinda messy.

https://github.com/inondle/django-template-benchmark

The main thing I want to improve is the way that test cases are run and
implemented. To add a test case in this implementation you would have to:

Write a function and decorate it with @cprofile
-

Create a new elif statement at the bottom and check for a keyword
-

Run the script with -t

While this isn't a terrible work flow it leaves a lot to be desired. I
would like to make it more like how the unittest module works with a setup
and test method but rather than checking assertions it just profiles the
code and prints out a pstats log for each test case. The pstats log can
then be rendered further into a call graph or something else.

I've tried to build a profiler class which uses method introspection to run
tests but it gets really complicated really fast. I've looked online and
can't find a way to subclass or extend the unittest module to do this. Is
there a way that I could get the feel of a unittest module but for
profiling code instead of running unit tests?

I also need to improve the templates that I run. Right now they are very
simple and only render a few lines with a pretty minimal context. If anyone
has suggestions on test templates I'm all ears.

--
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/cdc48345-84dd-4010-bf4a-7527b317ab12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bringing some popular must have django tools/packages under django org umbrella

2016-03-19 Thread Matías Iturburu

2016-03-16 6:24 GMT-03:00 James Pic :

> What do you mean stuck? Aren't you supposed to port the packages and
> submit a patch in that case? How are you stuck ?
>

Alright... I don't know you but no, that doesn't quite work that way.
Even if I submit a patch I wouldn't be able to:
- Merge it into mainline.
- Upload the patched version to pypi.

So it's a no-starter, I can't rely on my fork, not for production, as I
should guarantee that the package it's, at least, as tested as mainline,
which usually involves non-trivial infrastructure.

> I know the first portings are hard but once you've ported a dozen it
> becomes piece of cake so don't be afraid of trying ! And please contribute
> to the apps !!
>
> I know some people who only open issues and never submit a patch on
> github, isn't that super annoying?
>
Really? you go around asking users to do the work of maintainers?



> On Mar 16, 2016 5:38 AM, "Matías Iturburu"  wrote:
>
>> I recently got stuck upgrading a project to 1.9 due to a lot of useful
>> packages being not maintained:
>>
>> - django-endless-pagination: a substitute for django-pagination while it
>> didn't had python3 support
>> - django-taggit-templatetags: from when django-tagging didn't had python3
>> support.
>>
>> django-registration was another must have that recently resurfaced but
>> the same situation spawned django-registration-redux.
>>
>> Would it be too much a hassle to open an django-contrib organization with
>> less friction provide support for orphaned projects?
>>
>> 2015-11-24 16:27 GMT-03:00 Marc Tamlyn :
>>
>>> This is something the core team discussed in Amsterdam. I believe there
>>> was consensus to trial it with Django registration. I should catch up with
>>> James and see if it is transferred. If this goes well I see no reason why
>>> not.
>>>
>>> The biggest problem is the selection of packages, we have historically
>>> wanted to avoid too much bikeshedding. Initially it's likely to be mostly
>>> relatively inactive small utilities I think. But I think we are open to
>>> being more risky here.
>>>
>>> M
>>> On 24 Nov 2015 7:02 pm, "Asif Saifuddin"  wrote:
>>>
 The projects will have the official tool status + the maintainer of the
 projects will be able to collaborate better with django core team? less
 risk of being abandoned by the maintainers etc.

 IMHO

 On Wed, Nov 25, 2015 at 12:31 AM, Collin Anderson  wrote:

> Hi,
>
> Say a little bit more: What would be the goal? What would you hope
> would be accomplished by doing this?
>
> Thanks,
> Collin
>
> On Tuesday, November 24, 2015 at 1:27:11 PM UTC-5, Asif Saifuddin
> wrote:
>>
>> How is the idea? tools like django-debug-toolbar, django-silk,
>> django-taggit, django-filter etc and some more de facto tools under the
>> umbrella of django github org?
>>
>> Regards
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/bIzfHebE2sw/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/70062405-3ccd-49b2-9118-ec1679203cd1%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 http://groups.google.com/group/django-developers.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/CAKAqTgrnMoqy-%3DdDUx31Dgru6XTzT3e-T%3DhspY-CDK5tV9k1gQ%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

Re: FileField and ImageField

2016-03-19 Thread Josh Smeaton

It seems like FileField should delegate some of these methods to an 
underlying Storage backend, no? I don't know what the implications to 
back-compat would be, but the idea seems like a sensible one to start with. 
The storage backend API may need to grow some additional methods to 
verify/validate paths and filenames or it might already have the correct 
methods needed for FileField to work. Fields should do all of their 
path/storage IO via their storage object though.


On Thursday, 17 March 2016 12:16:00 UTC+11, Cristiano Coelho wrote:
>
> To add a bit more about this, it seems that FileField is really meant to 
> be working with an OS file system, making it harder to use a custom Storage 
> that sends data to somewhere like AWS S3 where basically everything is a 
> file (there are no real folders, just key prefixes)
>
> These 3 functions inside FileField are the culprits:
>
> def get_directory_name(self):
> return 
> os.path.normpath(force_text(datetime.datetime.now().strftime(force_str(self.upload_to
>
> def get_filename(self, filename):
> return 
> os.path.normpath(self.storage.get_valid_name(os.path.basename(filename)))
>
> def generate_filename(self, instance, filename):
> # If upload_to is a callable, make sure that the path it returns is
> # passed through get_valid_name() of the underlying storage.
> if callable(self.upload_to):
> directory_name, filename = os.path.split(self.upload_to(instance, 
> filename))
> filename = self.storage.get_valid_name(filename)
> return os.path.normpath(os.path.join(directory_name, filename))
>
> return os.path.join(self.get_directory_name(), 
> self.get_filename(filename))
>
>
>
> They basically destroy any file name you give to it even with upload_to. 
> This is not an issue on a storage that uses the underlying file system, but 
> it might be quite an issue on different systems, in particular if file 
> names are using slashes as prefixes.
>
> So what I did was to override it a bit:
>
> class S3FileField(FileField):
>  
> def generate_filename(self, instance, filename):
> # If upload_to is a callable, make sure that the path it returns is
> # passed through get_valid_name() of the underlying storage.
> if callable(self.upload_to):
> filename = self.upload_to(instance, filename)
> filename = self.storage.get_valid_name(filename)
> return filename
>
> return self.storage.get_valid_name(filename)
>
>
> And all S3 issues gone! I wonder if this is the best way to do it. It 
> would be great to have an additional keyword argument or something on the 
> File (and image) fields to let the above functions know that they should 
> not perform any OS operation on paths but seems like it would cause a lot 
> of trouble.
>

-- 
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/b1cbecc8-3cd0-455f-84bc-a87f079a418b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

On Thu, Mar 17, 2016 at 1:41 PM, Jacob Kaplan-Moss 
wrote:
>
>
> 1. Debugging errors:
>
> I found debugging errors that happen in a consumer to be *really*
> difficult -- errors mostly presented as things just silently not working.
> It took a ton of messing around with logging setups before I could get
> anything of use dumped to the console. This isn't strictly a Channels issue
> (I've noted similar problems with AJAX views and errors in Celery tasks),
> but I think Channels sorta brings the issue to a head.
>
> I think we need some better defaults, and simple, clear documentation, to
> make sure that exceptions go somewhere useful.
>

Yes, this is definitely an issue - right now, they pretty much only log to
stdout. I would like to at least:

a) Tie consumer errors into the same email-dispatch system for ADMINS as
view errors, by default
b) Write better docs about how to handle errors in a channels-like
scenario, and what they present as (as you said, generally just a lack of
response, like most networking code errors)


>
> 2. Static files:
>
> I had trouble getting static files served. I'm used to using Whitenoise (
> http://whitenoise.evans.io/en/stable/) for small-to-medium-ish sites that
> don't need a proper static server, but of course it doesn't work with
> Channels since Channels doesn't use WSGI! I found the (undocumented)
> StaticFilesConsumer (
> https://github.com/jacobian/channels-example/blob/master/chat/routing.py#L5-L8),
> but that feels less than ideal.
>
> I think this might be an opportunity, however. If Daphne learns how to
> serve static files (perhaps via optional integration with Whitenoise?),
> this would actually make static media in Django a bit easier by default.
>
> [I would be happy to work on this if I get a thumbsup.]
>

The static files consumer thing is merely for runserver, to match the
capabilities of the existing WSGI one. We could take it further and make it
an official public API, or work on something more reusable, or use
whitenoise.

It's worth noting that you can wrap ASGI consumers in something approaching
middleware inside Django - that's what StaticFilesConsumer does to
ViewConsumer - so maybe we should consider making this a more formal thing
and having a nice API for applying them.


>
> 3. WebSocket routing:
>
> Channels routes all WebSocket connections to a single set of consumers
> (the `websocket.*` consumers). This means that if you want multiple
> WebSocket URLs in a single app you need to manually parse the path. And, to
> make things more complicated, you only get the WebSocket path passed in the
> connection message, so you have to also use a channel session to keep track.
>
> This feels like a distinct step back from the URL routing we already have
> in Django, and it was surprising to me to have to do this by hand. It
> definitely felt like Channels is missing some sort of WebSocket URL router.
>
> I had a brief chat with Andrew, who indicates that he'd planned for this
> to be a post-1.0 feature. I'm not sure I agree - it feels pretty
> fundamental - but I'd like to hear other thoughts.
>
>
 So, Florian's idea above is interesting, but unfortunately puts the
HTTP-like parts at the outer level, which means it makes no sense for
someone doing routing from something like a WAMP or SMS protocol server (to
pick two protocols people might implement at some point).

The idea I had in my head looked more like this:

consumers = {
'sms.receive': incoming_sms,
'websocket.connect': UrlRouter(
url("^$", root_ws_connect),
url("^chat/([^/]+)/$", chat_ws_connect),
),
'websocket.receive': UrlRouter(
url("^$", root_ws_receive),
url("^chat/", chat_ws_receive),
),
}

Where UrlRouter is a class that you configure with URLs the same way views
are done, and then its __call__ merely passes the message down to the right
consumer.

But yes, we do need this.

Andrew

-- 
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/CAFwN1uoBX7SRPkyzyzR4p220LUj1L0%2BYnse6%3D%3Di8o2Tp_9gsbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: FileField and ImageField

2016-03-19 Thread Cristiano Coelho

To add a bit more about this, it seems that FileField is really meant to be 
working with an OS file system, making it harder to use a custom Storage 
that sends data to somewhere like AWS S3 where basically everything is a 
file (there are no real folders, just key prefixes)

These 3 functions inside FileField are the culprits:

def get_directory_name(self):
return 
os.path.normpath(force_text(datetime.datetime.now().strftime(force_str(self.upload_to

def get_filename(self, filename):
return 
os.path.normpath(self.storage.get_valid_name(os.path.basename(filename)))

def generate_filename(self, instance, filename):
# If upload_to is a callable, make sure that the path it returns is
# passed through get_valid_name() of the underlying storage.
if callable(self.upload_to):
directory_name, filename = os.path.split(self.upload_to(instance, 
filename))
filename = self.storage.get_valid_name(filename)
return os.path.normpath(os.path.join(directory_name, filename))

return os.path.join(self.get_directory_name(), 
self.get_filename(filename))



They basically destroy any file name you give to it even with upload_to. 
This is not an issue on a storage that uses the underlying file system, but 
it might be quite an issue on different systems, in particular if file 
names are using slashes as prefixes.

So what I did was to override it a bit:

class S3FileField(FileField):
 
def generate_filename(self, instance, filename):
# If upload_to is a callable, make sure that the path it returns is
# passed through get_valid_name() of the underlying storage.
if callable(self.upload_to):
filename = self.upload_to(instance, filename)
filename = self.storage.get_valid_name(filename)
return filename

return self.storage.get_valid_name(filename)


And all S3 issues gone! I wonder if this is the best way to do it. It would 
be great to have an additional keyword argument or something on the File 
(and image) fields to let the above functions know that they should not 
perform any OS operation on paths but seems like it would cause a lot of 
trouble.

-- 
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/04eea39c-311d-4055-a769-3a9830ce08f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

Perhaps it is a bit early for this but Is there anywhere origin is checked
against ALLOWED_HOSTS ?

Middleware support would be nice to but I guess you'll come to that when
implementing user authentication.

Keep up the great work !

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

[GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

I'm hoping to add a feature that I've thought Django has needed for a long
time, and thought that Google Summer of Code would be an excellent
opportunity for it. Basically, it would be an API for defining 'Conditions'
and applying them to Views. Common usages would include restricting views
based on whether a user is the owner of an object (as determined by a
ForeignKey), whether a group-style object has the capacity to add another
object to its members, whether the user has a certain permission, etc.
Though Django recently added some Auth-related mixins (e.g.
UserPassesTestMixin
)

that get the job done in simple situations, however the lack of separation
between view-related functionality and condition-evaluation code severely
limits their usability in more complex situations.

My proposal is
still not entirely done (no timeline and the implementation section needs a
lot of clarification), but it looks like time is getting fairly tight so I
figured I should reach out ASAP. I was particularly hoping to get feedback
on the part of my proposal where I assert that it is necessary in the first
place ('The Problem(s)').

Questions:
1. How clear and convincing is the section describing what's wrong with the
current solution ('The Problem(s)')? Any criticisms on that section would
be very welcome.
2. Are you or anyone you know interested in mentoring on this project?

--
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/ef9f3369-cbb6-4cef-b538-768d4961ef38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

Hi Vincent,

I think you make some good points - in particular, I think includes are
probably a necessity, as you say. However, I disagree we should let people
have either channel->url or url->channel; I'd like us not to try and give
people multiple ways to do things if we can help it, especially in an
ecosystem of third-party apps.

You can't rename routing.py to channels.py, however, as then the import
names will clash with the `channels` third-party app if the user hasn't
turned on absolute imports.

I'd build on your proposal and say the following:

---

Routing should be a list of pattern matches rather than a dict, so you can
spread it across multiple includes sensibly. Each entry in the list will be
a route() match object that takes a channel name (it has to be a name, no
regular expressions here) as a required argument, and an optional `path`
argument that's a regular expression matched against the incoming message
`path`.

In fact, the routing will be generic, so you can regex against any primary
message attribute you know will be present - for example, `method` for
HTTP, or in the SMS example, by country code. It'll work like URL routing
too and let you capture groups to be passed to the consumer (but only by
name, to avoid confusion when a user matches against multiple message
attributes and there's no defined ordering).

The include() function will take any keyword argument and do prefixing like
it does now for URLs.

Example:

routing = [
route("http.request", ViewConsumer),
route("websocket.connect", path="^chat/(?P[^/]+)/$", ChatConnect),
route("sms.receive", sender="+44(?P[0-9]+)$",
UkSmsConsumer),
include(path="^notifications", "notification.routing.routing"),
]

It also means that the simple example case stays quite readable:

routing = [
route("websocket.connect", ws_connect),
route("websocket.receive", ws_receive),
route("websocket.disconnect", ws_disconnect),
]

We can also have channels upconvert the old dict format into this trivially
to preserve all the existing code and examples, like Jacob's article.

Andrew

On Fri, Mar 18, 2016 at 3:48 AM, Vincent  wrote:

> Jacob, Florian, Andrew,
>
> I've spent the last 200 minutes thinking this through and writing, and
> here's what I've come up with:
>
> https://gist.github.com/orokusaki/c67d46965a4ebeb3035a
>
> Below are the full contents of that Gist (but I recommend the Gist for
> formatting).
>
> I also created https://github.com/andrewgodwin/channels/issues/87 last
> weekend (re: your static files point above, Jacob).
>
> ### Problem
>
>   1. Channel / URL routing is 2-dimensional (compared with 1D URL handling
> in Django)
>   2. This creates a chicken / egg problem between channel name and URL path
>   2. That's illustrated by the discrepancy between Florian's URL ->
> channel and Andrew's channel -> URL
>   3. Put a Channel on the Y axis and URL are on the X axis, and the
> intersection is where a Consumer comes into play
>
> ### Considerations
>
> Here are some design considerations for my API proposal:
>
>   1. Includes - because nobody wants to all of their channels / URLs in a
> project-level module
>   2. URL generation for channels with URLs
>   3. The following duplicate include functionality works perfectly in
> Django currently with URLs
>   4. `urlpatterns` are kepts in `urls.py`
>   5. So, I've renamed `routing.py` to `channels.py` - after all, we're
> defining `channelpatterns`
>   6. Either channel name OR URL has to come first, so that we don't need a
> 2D graph in Python for routing consumers
>
> Project-level channels:
>
> # channels.py
> channelpatterns = [
> channel(r'^websocket\.', include('chat.channels',
> namespace='chat')),
> channel(r'^websocket\.', include('game.channels',
> namespace='game')),
> channel(
> r'^websocket',
> name='active-visitors',
> urls=[
> url(r'^active-visitors/$', VisitorCount.as_consumer()),
> ]
> ),
> ]
>
> App-level channels:
>
> # game/channels.py
> channelpatterns = [
> channel(
> r'^receive',
> name='receive',
> urls=[
> url(r'^game/moves/up/$', Move.as_consumer(direction='up'),
> name='move-up'),
> url(r'^game/moves/down/$',
> Move.as_consumer(direction='down'), name='move-down'),
> ]
> ),
> ]
>
> Channel routing would be handled similar to URLs in Django.
>
> Given the above, getting the Channel URL for "moving up" in game could be:
> `{% channel 'game:receive:move-up' %}`
>
> Here's an example of `websocket.connect` @ `/game/moves/up/`
>
>   1. Encounter first match (the WebSocket channel named `chat`)
>   2. Include `chat.channels`
>   3. Determine there is no match
>   4. Encounter second match (the WebSocket channel named `game`)
>   5. Include `game.channels`
>   6. Encounter first URL match (the

Re: Feedback on Django Channels

Also note, I just copy-pasted the same SyntaxError (kwarg before arg).

On Friday, March 18, 2016 at 3:40:22 PM UTC-4, Vincent wrote:
>
> Hey Andrew,
>
> Thanks for looking through all that, and for the reply.
>
> I like the simplicity of your updated examples. I started to make a 
> counter-example to suggest that `include` be inside of a `route` (
> https://gist.github.com/orokusaki/c0c934013ee7911071ef).
>
> But then, as I thought through this, I think I like your example almost* 
> exactly like it is, but I'm afraid there might be a problem:
>
> Given your example, any message how would a 'websocket.connect' message at 
> the path `notifications/foo/` be routed, giving this example:
>
> routing = [
> route("websocket.connect", ChatConnect),
> include(path="^notifications", "notification.routing.routing"),
> ]
>
> Given that the chat route is the first match, wouldn't the notifications 
> route never be used? Would path need to be required, so that the matching 
> would be similar to `urlpatterns`? Otherwise, we're allowing routing based 
> on channel name or path again? Maybe I'm misunderstanding.
>
> On Friday, March 18, 2016 at 10:58:41 AM UTC-4, Andrew Godwin wrote:
>>
>> Hi Vincent,
>>
>> I think you make some good points - in particular, I think includes are 
>> probably a necessity, as you say. However, I disagree we should let people 
>> have either channel->url or url->channel; I'd like us not to try and give 
>> people multiple ways to do things if we can help it, especially in an 
>> ecosystem of third-party apps.
>>
>> You can't rename routing.py to channels.py, however, as then the import 
>> names will clash with the `channels` third-party app if the user hasn't 
>> turned on absolute imports.
>>
>> I'd build on your proposal and say the following:
>>
>> ---
>>
>> Routing should be a list of pattern matches rather than a dict, so you 
>> can spread it across multiple includes sensibly. Each entry in the list 
>> will be a route() match object that takes a channel name (it has to be a 
>> name, no regular expressions here) as a required argument, and an optional 
>> `path` argument that's a regular expression matched against the incoming 
>> message `path`.
>>
>> In fact, the routing will be generic, so you can regex against any 
>> primary message attribute you know will be present - for example, `method` 
>> for HTTP, or in the SMS example, by country code. It'll work like URL 
>> routing too and let you capture groups to be passed to the consumer (but 
>> only by name, to avoid confusion when a user matches against multiple 
>> message attributes and there's no defined ordering).
>>
>> The include() function will take any keyword argument and do prefixing 
>> like it does now for URLs.
>>
>> Example:
>>
>> routing = [
>> route("http.request", ViewConsumer),
>> route("websocket.connect", path="^chat/(?P[^/]+)/$", 
>> ChatConnect),
>> route("sms.receive", sender="+44(?P[0-9]+)$", 
>> UkSmsConsumer),
>> include(path="^notifications", "notification.routing.routing"),
>> ]
>>
>> It also means that the simple example case stays quite readable:
>>
>> routing = [
>> route("websocket.connect", ws_connect),
>> route("websocket.receive", ws_receive),
>> route("websocket.disconnect", ws_disconnect),
>> ]
>>
>> We can also have channels upconvert the old dict format into this 
>> trivially to preserve all the existing code and examples, like Jacob's 
>> article.
>>
>> Andrew
>>
>> On Fri, Mar 18, 2016 at 3:48 AM, Vincent  wrote:
>>
>>> Jacob, Florian, Andrew,
>>>
>>> I've spent the last 200 minutes thinking this through and writing, and 
>>> here's what I've come up with:
>>>
>>> https://gist.github.com/orokusaki/c67d46965a4ebeb3035a
>>>
>>> Below are the full contents of that Gist (but I recommend the Gist for 
>>> formatting).
>>>
>>> I also created https://github.com/andrewgodwin/channels/issues/87 last 
>>> weekend (re: your static files point above, Jacob).
>>>
>>> ### Problem
>>>
>>>   1. Channel / URL routing is 2-dimensional (compared with 1D URL 
>>> handling in Django)
>>>   2. This creates a chicken / egg problem between channel name and URL 
>>> path
>>>   2. That's illustrated by the discrepancy between Florian's URL -> 
>>> channel and Andrew's channel -> URL
>>>   3. Put a Channel on the Y axis and URL are on the X axis, and the 
>>> intersection is where a Consumer comes into play
>>>
>>> ### Considerations
>>>
>>> Here are some design considerations for my API proposal:
>>>
>>>   1. Includes - because nobody wants to all of their channels / URLs in 
>>> a project-level module
>>>   2. URL generation for channels with URLs
>>>   3. The following duplicate include functionality works perfectly in 
>>> Django currently with URLs
>>>   4. `urlpatterns` are kepts in `urls.py`
>>>   5. So, I've renamed `routing.py` to `channels.py` - after all, we're 
>>> defining `channelpatterns`
>>>   6. Either channel name OR URL has to come

Re: TransactionManagementError is raised when autocommit …

2016-03-19 Thread Tore Lundqvist


Correction:

> I can't use atomic blocks 

This is not true.

"You can use atomic just over the section that causes the error", this has 
been suggested to me multiple times and I thought I had no use for it but 
it was actually very useful in many cases. 
With that technic and with the Django patch Aymeric suggested I managed to 
solve my problem without patching set_rollback().

Thanks everyone for helping me with this!
Tore

-- 
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/1d1cab1a-439d-4c47-bc07-0c6e6da45b03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

My original inspiration actually was Django Rest Framework, but I wanted to 
show that I had actually thought it out and that it is indeed possible to 
implement (albeit not quite as cleanly as DRF does it). I'll try to finish 
a more detailed write-up of how they compare, but in short they are very 
similar. In terms of overall paradigm, the largest difference is that DRF's 
"permissions" are designed exclusively for being run given the request or 
the request and the result of get_object(). My proposal, on the other hand, 
would allow conditions to be written that don't require these arguments and 
in fact require other arguments, although it does provide appropriate 
sub-classes for these extremely common usage cases.

On Thursday, March 17, 2016 at 12:55:04 AM UTC+8, Connor Boyle wrote:
>
> I'm hoping to add a feature that I've thought Django has needed for a long 
> time, and thought that Google Summer of Code would be an excellent 
> opportunity for it. Basically, it would be an API for defining 'Conditions' 
> and applying them to Views. Common usages would include restricting views 
> based on whether a user is the owner of an object (as determined by a 
> ForeignKey), whether a group-style object has the capacity to add another 
> object to its members, whether the user has a certain permission, etc. 
> Though Django recently added some Auth-related mixins (e.g. 
> UserPassesTestMixin 
> )
>  
> that get the job done in simple situations, however the lack of separation 
> between view-related functionality and condition-evaluation code severely 
> limits their usability in more complex situations.
>
> My proposal  
> is still not entirely done (no timeline and the implementation section 
> needs a lot of clarification), but it looks like time is getting fairly 
> tight so I figured I should reach out ASAP. I was particularly hoping to 
> get feedback on the part of my proposal where I assert that it is necessary 
> in the first place ('The Problem(s)').
>
> Questions:
> 1. How clear and convincing is the section describing what's wrong with 
> the current solution ('The Problem(s)')? Any criticisms on that section 
> would be very welcome.
> 2. Are you or anyone you know interested in mentoring on this project?
>

-- 
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/a925f325-1089-4eef-82f6-11bcc2ac89f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

2016-03-19 Thread Ryan Hiebert


> On Mar 18, 2016, at 9:58 AM, Andrew Godwin  wrote:
> 
> routing = [
> route("http.request", ViewConsumer),
> route("websocket.connect", path="^chat/(?P[^/]+)/$", ChatConnect),
> route("sms.receive", sender="+44(?P[0-9]+)$", 
> UkSmsConsumer),
> include(path="^notifications", "notification.routing.routing"),
> ]

Something's up with this example, it has postional arguments after keyword 
arguments, which is invalid Python. Is there supposed to be a keyword used for 
the final parameters?

-- 
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/68C930D0-1C2E-4CF4-B3B8-DA8450C468AB%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: MySQL data loss possibility with concurrent ManyToManyField saves

2016-03-19 Thread Karen Tracey

This is the 2nd major issue I can recall caused by MySQL default of
REPEATABLE READ transaction isolation level. I think Django should simply
switch itself to a default of using READ COMMITTED, consistent with (all?)
other supported database backends, and document how, if a user really
really wants to use REPEATABLE READ, they can do so (I assume Django could
allow that?), and what known problems when using basic Django functions
they may run into if they do so.

I fear our existing approach of documenting how certain functions don't
work by default on MySQL (e.g. get_or_create) is not really helping the
majority of our users. I believe switching instead to making Django code
itself work by default on MySQL would be a better long-term solution for
those who use MySQL with Django, and avoid future cases like this one that
has been discovered (years after we knew get_or_create was broken by
default transaction isolation level on MySQL).

On Mon, Mar 14, 2016 at 11:15 AM, Tim Graham  wrote:

> Could some MySQL users take a look at ticket #26347 [0] and recommend how
> to proceed? I think it's probably not a new issue but I'm a bit surprised
> it hasn't come up before if so.
>
> [0] https://code.djangoproject.com/ticket/26347
>
> --
> 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/286b0efb-673f-42d7-a1f3-5de76fc039c5%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/CACS9rae4U0e80-h%3DesTXFUi%3DLxWQ-XiMAp%3DAdkXcR0FnJVT2Cg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

2016-03-19 Thread Florian Apolloner

On Thursday, March 17, 2016 at 5:42:05 PM UTC+1, Jacob Kaplan-Moss wrote:
>
> Channels routes all WebSocket connections to a single set of consumers 
> (the `websocket.*` consumers). This means that if you want multiple 
> WebSocket URLs in a single app you need to manually parse the path. And, to 
> make things more complicated, you only get the WebSocket path passed in the 
> connection message, so you have to also use a channel session to keep track.
>

Yes, this seems like a major pain point, especially since the routing does 
not scale if you add another app, ie you need to add a wrapper which then 
dispatches to the individual connect routines. In a best case scenario I'd 
just have to add another router in the settings and get everything 
dispatched to the correct handlers (in that sense, the ROUTING setting 
should allow for multiple entries). Basically I think there needs to be a 
way to scope websocket.* to a single session(type) [And we should have this 
from the start]. Maybe something along the lines of:
```
channel_routing = {
  '^chat/(?P\w+)': {
'websocket.connect': …,
'websocket.receive': …,
  },
  '^notifies/…': {
'websocket.connect': …,
'websocket.receive': …,
  },
  '^.*': {
'http.request': my_handler
  }
}
```

So in essence: If the URL starts with "chat", the handlers for this "scope" 
should get called with room as argument (the data is already there, ) -- 
just like normal views. Same goes for notifications… I realize that this 
definition seems overly complicated, but this is the feature set I'd expect 
personally. Theoretically, the frontend server should have this information 
over the whole (websocket)session anyways and there shouldn't be any need 
for channel_session at all (That said, channel_session does not work with 
signed cookies ;)).

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/5f957bbb-f025-4d85-97c5-a9a62cf86296%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

FileField and ImageField

2016-03-19 Thread Cristiano Coelho

I am recently trying to make an aws S3 storage (I know there are a few
libraries in there but I needed some customization). The storage works fine
so far!

However, there are some implementation details on FileField and ImageField,
in particular the function
generate_filename
https://github.com/django/django/blob/master/django/db/models/fields/files.py#L310

that is called before saving a model (and its file/image field). That code
assumes the file uses standar file paths based on your current operative
system. This creates quite some complications on S3 for example where all
the paths to simulate folders uses a "/", so if you are in Windows and your
file name is something like "hello/my/file.txt" it will overwrite your file
name to be "hello\\my\\file.txt" which is something I don't want as I have
explicitly created an upload_to callable to generate a very specific file
name (and that it shouldn't be changed).
Looking deeper it seems like the whole FileField implementation relies on a
directory and file structure, which might not be always right.

How easy would it be to add customization to this? Is your only option
defining your own FileFilend and ImageField classes that override this
method?

--
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/35f921f4-9c22-40fa-bbea-ebfcb4c5d91f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

If we prefer to remove form related stuff from models, then we should
be able to register new default model forms:

models.py:

class YourModel(models.Model):
your_field = models.BooleanField()

forms.py:

class YourModelDefaultForm(django.?.ModelFormConfiguration):
class Meta:
help_texts = dict(your_field='your help text')

# Set it as default
django.?.register(YourModel, YourModelDefaultForm)

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

Re: Proposal: change to the way list_editable form data is submitted in the admin

2016-03-19 Thread Collin Anderson

I could see this feature being helpful. (Submitting the original data and
comparing it to be sure we don't silently have a merge conflict).

On Wed, Mar 16, 2016 at 11:14 PM, John C  wrote:

> Thanks. #11652 is a good description of the same problem in the context of
> the "change" page. I think that, in practice, it is more of a problem with
> a list_editable, since you're updating many records at once. This makes a
> "collision" with some other part of the system more likely.
>
> I think the approach outlined in #16549, which requires persisting a
> version number, would suffice but is not really necessary. I can understand
> wanting to make the solution applicable more widely than just one
> particular admin feature; however, the best solution depends on the
> context. In the case of #11652, optimistic locking is a good fit, because
> we can't assume the granularity of the different fields on the model.
> Whereas with list_editable, it's a bunch of records of the same type. It is
> quite safe to assume that we can consider the records that were updated by
> the user, compared to the values originally displayed, and do all these
> changes independently of one another. From this point of view, it is
> actually an optimization, to skip the update when there is no change.
>
> -John
>
> On Wednesday, March 16, 2016 at 8:21:40 PM UTC-5, Josh Smeaton wrote:
>>
>> I know this particular case has been discussed before. Here are two
>> related tickets (I think there's a better canonical ticket but I can't find
>> it just now): https://code.djangoproject.com/ticket/11652 and
>> https://code.djangoproject.com/ticket/16549
>>
>> I haven't done the required reading recently, so I can't comment on
>> whether or not your idea could be accepted. But hopefully those tickets
>> should provide a bit more information for investigation puproses.
>>
>>
>>
>> On Thursday, 17 March 2016 11:37:06 UTC+11, John C wrote:
>>>
>>> Hey,
>>>
>>> For the past five years, I've been using Django to manage a database of
>>> online applications. I absolutely love it! Makes my job so much easier.
>>>
>>> In general, any problems I run into, there's usually an easy workaround.
>>> But I wonder if that's even feasible in this case. Anyway, here's the
>>> problem: in managing submissions we make a lot of use of the list_editable
>>> attribute of ModelAdmin, particularly for status columns. It's extremely
>>> handy to be able to load up a list, filter it, and then make status changes
>>> to selected records all in one go.
>>>
>>> However, there are times when these status columns are also changing on
>>> their own, due to what's happening on the front end. I have to be very
>>> careful to ensure that this doesn't happen in between when I load an admin
>>> list and when I click "Save." If so, then I may end up overwriting the
>>> newly changed data, back to what it was when the list was loaded in my
>>> browser. This is because all rows are always saved, based on the data in
>>> the form inputs from the list.
>>>
>>> I propose that a copy of the list_editable values be sent along as a
>>> hidden form element (or, alternatively, that Javascript be used to detect
>>> values changed in response to user input). That way, in the admin form
>>> handler, only rows that have been intended to be changed would be updated
>>> to submitted values.
>>>
>>> It adds some complexity, sure, but are there any disadvantages I haven't
>>> thought of? From my perspective, it would solve a rather frustrating
>>> problem.
>>>
>>> Thanks,
>>> John Cronan
>>>
>>> --
> 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/1f970804-7b49-44da-916f-21270e4a3cac%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/CAFO84S5M7OB-CsHPAwVjze%2B9NkbiPbJ_qNd2SYVKm3hA5vsBhw%40mail.gmail.com.
For more options, visit

Re: Override the default form field for a model field

On Thu, Mar 17, 2016 at 2:17 PM, Tim Graham  wrote:
> It seems useful, but I'm not sure if it increases the coupling between model
> and forms in an undesirable way?

The coupling is already there because model fields sit right
in-between the db and form fields, so I don't know if it would
actually /increase/ the coupling.

Another way is to extract out all form related methods from model
fields (value_from_object(), save_form_data(), formfield()) into a new
class.

Then instead of this model:

dbfield -> model field <- formfield

You'd have:

form field
\
   modelformfield
  |
   model field
   /
dbfield

modelformfield would have the formfield(), value_from_object(), and
save_form_data().

Anyway, are you sure it's not another issue ? I mean, even if we
decide to move formfield(), shouldn't it have overridable defaults ?

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

Re: Feedback on Django Channels

Jacob, Florian, Andrew,

I've spent the last 200 minutes thinking this through and writing, and 
here's what I've come up with:

https://gist.github.com/orokusaki/c67d46965a4ebeb3035a

Below are the full contents of that Gist (but I recommend the Gist for 
formatting).

I also created https://github.com/andrewgodwin/channels/issues/87 last 
weekend (re: your static files point above, Jacob).

### Problem

  1. Channel / URL routing is 2-dimensional (compared with 1D URL handling 
in Django)
  2. This creates a chicken / egg problem between channel name and URL path
  2. That's illustrated by the discrepancy between Florian's URL -> channel 
and Andrew's channel -> URL
  3. Put a Channel on the Y axis and URL are on the X axis, and the 
intersection is where a Consumer comes into play

### Considerations

Here are some design considerations for my API proposal:

  1. Includes - because nobody wants to all of their channels / URLs in a 
project-level module
  2. URL generation for channels with URLs
  3. The following duplicate include functionality works perfectly in 
Django currently with URLs
  4. `urlpatterns` are kepts in `urls.py`
  5. So, I've renamed `routing.py` to `channels.py` - after all, we're 
defining `channelpatterns`
  6. Either channel name OR URL has to come first, so that we don't need a 
2D graph in Python for routing consumers

Project-level channels:

# channels.py
channelpatterns = [
channel(r'^websocket\.', include('chat.channels', 
namespace='chat')),
channel(r'^websocket\.', include('game.channels', 
namespace='game')),
channel(
r'^websocket',
name='active-visitors',
urls=[
url(r'^active-visitors/$', VisitorCount.as_consumer()),
]
),
]

App-level channels:

# game/channels.py
channelpatterns = [
channel(
r'^receive',
name='receive',
urls=[
url(r'^game/moves/up/$', Move.as_consumer(direction='up'), 
name='move-up'),
url(r'^game/moves/down/$', 
Move.as_consumer(direction='down'), name='move-down'),
]
),
]

Channel routing would be handled similar to URLs in Django.

Given the above, getting the Channel URL for "moving up" in game could be: 
`{% channel 'game:receive:move-up' %}`

Here's an example of `websocket.connect` @ `/game/moves/up/`

  1. Encounter first match (the WebSocket channel named `chat`)
  2. Include `chat.channels`
  3. Determine there is no match
  4. Encounter second match (the WebSocket channel named `game`)
  5. Include `game.channels`
  6. Encounter first URL match (the `/game/moves/up/` pattern)
  7. Delegate to `Move` consumer with default `direction='up'`

But wait, there's more :)

Since Channel + URL is 2-dimensional, I propose we allow `include` at the 
`url` level and at the `channel` level.

# channels.py
channelpatterns = [
channel(
r'^websocket\.receive$',
urls=[
url(r'^game/', include('chat.channels', namespace='game')),
]
),
]

Then:

# game/channels.py
channelpatterns = [
channel(
r'^$',
name='moves',
urls=[
url(r'^moves/up$', Move.as_consumer(direction='up'), 
name='move-up'),
url(r'^moves/down$', Move.as_consumer(direction='down'), 
name='move-down'),
]
)
]

Since I'm allowing `include` in a `channel` or any of its `urls`, either 
breadth-first search (giving URls / URL includes precedence) or depth-first 
search (giving channel includes precedence) could be used. I'd argue for 
breadth-first.

On Thursday, March 17, 2016 at 12:42:05 PM UTC-4, Jacob Kaplan-Moss wrote:
>
> Hi folks (and especially Andrew):
>
> I've just completed writing an example Channels app [1] for an article 
> about Channels [2]. Overall it was a super-pleasant experience: Channels 
> seems pretty solid, the APIs make sense to me, and I couldn't be more 
> excited about the new things this'll let me do! 
>
> In the interests of making this thing as solid as possible before we merge 
> it into Django, I do have some feedback on some of the hiccups I 
> encountered. Roughly in order of severity (as I perceive it), they are:
>
> 1. Debugging errors:
>
> I found debugging errors that happen in a consumer to be *really* 
> difficult -- errors mostly presented as things just silently not working. 
> It took a ton of messing around with logging setups before I could get 
> anything of use dumped to the console. This isn't strictly a Channels issue 
> (I've noted similar problems with AJAX views and errors in Celery tasks), 
> but I think Channels sorta brings the issue to a head. 
>
> I think we need some better defaults, and simple, clear documentation, to 
> make sure that exceptions go somewhere useful.
>
> 2. Static files:
>
> I had trouble getting static files served. I'm used to

Re: Bringing some popular must have django tools/packages under django org umbrella

FTR, there's also Djangonauts which have been there for a while:
https://github.com/djangonauts

Sorry, I tried not to look uncivil - and yet I fail to see where I
was, but definitely re-reading and thinking about it (I'm not an
english native speaker). Please anyone feel free to PM me and point me
to where I was uncivil.

Best ;)

James

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

Re: [GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)