Re: CTRL-BREAK still make sense on Windows for `runserver`?

[William Vincent]

Ok, thanks for the link Matthew. Just thought I'd bring it up in case 
things had changed. Seems status quo is fine for now but if Windows 
keyboards continue to remove the Pause/Break key might make sense to add 
`Control-C` as Adam notes or eventually switch over.

On Tuesday, June 22, 2021 at 6:02:39 AM UTC-4 f.apo...@gmail.com wrote:

> As long as runserver (usually) properly shuts down when CTRL-C is hit, 
> then it imo makes sense to change the text -- especially if that is the 
> only thing accessible on some keyboards.
>
> The usually above is because someone might have a bare except that is hit 
> that moment and as such the process might not shut down.
>
> On Tuesday, June 22, 2021 at 7:58:47 AM UTC+2 carlton...@gmail.com wrote:
>
>> I too realise I don't have a(n obvious) break key but have been happily 
>> hitting CTRL-C. 
>>
>> On Monday, 21 June 2021 at 23:53:15 UTC+2 Adam Johnson wrote:
>>
>>> Would it be bad to have Django respond to both shortcuts?
>>>
>>
>> I think as a matter of fact it does. At least using PowerShell/Win10/Etc 
>> — Looking at Matthew's link, we don't do either of the things that would 
>> inhibit this. 樂
>>
>> Looking at it from Will's POV (writing introductory guides) the output 
>> text of runserver might be a bit problematic:
>>
>> "Quit the sever with CTRL-BREAK" — Errrmmm... Where's that then? 
>>
>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/751d9d0f-a387-498f-89be-8a9c7484eea4n%40googlegroups.com.

Re: Getting Started.

[Vincent TOSSOU]

Hi, I'm Web Front developer!

Le sam. 26 déc. 2020 à 18:53, vamshi krishna janumpally <
vamshiguptha1...@gmail.com> a écrit :

> Hey guys, getting started with open source contribution. I would like to
> contribute to the Django community.  Any help regarding getting started
> would be greatly appreciated.
> Have knowledge in various domains: Machine Learning, Deep Learning, Data
> Science, web development, VCS.
> Thank You :)
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/85a3e227-081e-4f2d-afd9-31515ab0636bn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAN7mm%2BRrhsXpyD9hAXoLqO_dcsbgb7vBC1F91STNisPN83wysQ%40mail.gmail.com.

Re: Google Patch Rewards program

[William Vincent]

This is great! To the extent we have this teed up internally, makes it much 
easier for DSF to go to Google and coordinate. And even if Google doesn't 
pan out, having structure makes it easier for us to, for example, find 
funding if some fundraising projects in the works pan out.

On Tuesday, December 31, 2019 at 11:40:15 AM UTC-5, Dan Davis wrote:
>
> Another good security improvement would be to allow the database password 
> and other database information to support AWS Secrets Manager, Goolge 
> Secrets Management, and HashiCorp vault (+ others).
> I have done this in a private package used at the National Library of 
> Medicine, but my package is both private and limited to RDS PostgreSQL and 
> AWS Secrets Manager.
>
> On Tue, Dec 31, 2019 at 11:25 AM Dan Davis  > wrote:
>
>> Taymon Beal writes:
>> > First-class integration with one or more secrets management systems, 
>> both to generally contain secrets better and more specifically 
>> > so people aren't so tempted to check SECRET_KEYs and database passwords 
>> into source control. (I think this was mentioned in the list of GSoC 
>> project ideas.)
>>
>> What secrets management systems are you thinking about?   I wrote 
>> confsecrets, whose Django integration never worked right, assuming that I'd 
>> port it to support the following:
>> * HashiCorp vault
>> * AWS Secrets Manager
>> * Google Secrets Management
>>
>> I also need to switch it from cryptdome to cryptography or make it 
>> agnostic on these.
>>
>> P.S. - I have some very limited applied cryptography knowledge - couple 
>> chapters of Bruce Schneier and some hands-on learning, such as securing 
>> single license features with signatures based on my employer's license 
>> signing private key, and discovering that a customer literally pulled one 
>> set of feature.xml/feature.sig files from one tarball, and another from 
>> another tarball to game my home-grown licensing system.  I helped that 
>> company eventually move to a Secure USB dongle, and that was my last moment 
>> of systems software development :)
>>
>> On Sat, Dec 28, 2019 at 11:23 PM Taymon A. Beal > > wrote:
>>
>>> (Disclosure: I'm on Google's security team, and my views on this topic 
>>> are informed by what kinds of things we tend to look for in Web frameworks, 
>>> but here I don't speak for them, only for myself.)
>>>
>>> Beyond those already mentioned, here are some potential security 
>>> improvements I'd like to see in Django:
>>>
>>>- Support for contextual autoescaping in the template system. The 
>>>current autoescaping behavior is better than nothing, but it still makes 
>>>XSS far too easy, since different kinds of strings are XSS sinks in 
>>>different contexts. 
>>>
>>> https://github.com/google/closure-templates/blob/master/documentation/concepts/auto-escaping.md
>>>  shows 
>>>an example of how to do this sort of thing more securely.
>>>- First-class integration with one or more secrets management 
>>>systems, both to generally contain secrets better and more specifically 
>>> so 
>>>people aren't so tempted to check SECRET_KEYs and database passwords 
>>> into 
>>>source control. (I think this was mentioned in the list of GSoC project 
>>>ideas.)
>>>- Capability-based authorization. Right now, you have to explicitly 
>>>check for all relevant permissions everywhere, and if you forget, or 
>>> even 
>>>if you accidentally include the wrong variable in a template, you can 
>>> leak 
>>>data or worse. It'd be much safer if the allowed permissions could be 
>>>defined at a single choke point, and from there, all model access within 
>>> a 
>>>request could be mediated by the specified authorization rules. Ideally 
>>>data that the current user isn't supposed to see would not even be 
>>> fetched 
>>>from the database.
>>>
>>> Taymon
>>>
>>> On Sat, Dec 21, 2019 at 11:29 PM Asif Saif Uddin >> > wrote:
>>>
 Really good plans Adam!

 On Saturday, December 21, 2019 at 11:51:11 PM UTC+6, Adam Johnson wrote:
>
> I just saw Google is expanding their Patch Rewards program for open 
> source security improvements: 
> https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html
>
> They are offering two tiers of rewards - $5,000 or $30,000 - for  open 
> source projects making security improvements. I think Django would find 
> it 
> hard to fit in the "small" tier - we generally fix known vulnerabilities 
> quickly - but we could use the "large" tier to fund a bigger GSoC style 
> project. I suspect it would need active involvement from a DSF member to 
> push it through. Not sure how the funding would work in terms of DSF and 
> paying for development time on the project.
>
> Some projects that could fit:
>
>- 2FA built-in to django.contrib.auth (as suggested for GSoC as 
>well in this thread: 
>
> 

Re: Make Development More Accessible

[William Vincent]

I think the way Rails does it, aka with well-done newcomers guide 
(https://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) is 
worth looking at, as Carlton notes. A bit more streamlined than the current 
Django How To Contribute Guides.

Incidentally, Carlton and I will be having a chat with DHH of Ruby on Rails 
fame in September for the DjangoChat podcast so if there are any questions 
we should pose to him on managing the Rails community, do pass along to us. 
Certainly I'll ask him about issue tracking!

On Thursday, August 8, 2019 at 3:08:39 PM UTC-4, Tim Graham wrote:
>
> Although I'm not engaged too much with Django development now, a big 
> drawback of moving to GitHub issues for me would be that I could no longer 
> do a Google search like "something something site:code.djangoproject.com". 
> I could pretty much always find the ticket I was looking for that way. 
> Maybe GitHub issue search would be just as good but I find Google results 
> (with a snippet from the page) more useful.
>
> Another migration consideration is that Trac tickets are formatted using a 
> different syntax than GitHub issues.
>
> A migration feels like weeks of work and it doesn't strike me as a "heck 
> yea!" improvement. There would probably be benefits and drawbacks. As 
> Carlton said, I think it's time that could be more usefully allocated.
>
> I wonder how putting issues on GitHub would increase engagement? Is it 
> that Trac isn't discoverable from GitHub? What if GitHub let us redirect 
> https://github.com/django/django/issues (with the "Issues" tab) to 
> code.djangoproject.com?
>
> On Thursday, August 8, 2019 at 4:48:14 AM UTC-4, Carlton Gibson wrote:
>>
>> Just on this point: 
>>
>> > I agree with Andrew Godwins statement on Django loosing many 
>> contributors over the years and being in largely maintenance mode. 
>>
>> First, I'm not sure Andrew actually said this. Rather I think he reported 
>> is a point raised. However...
>>
>> I hear this kind of thing said. It ties-in with the "Django is boring" 
>> trope, when that's not meant as a compliment. 
>>
>> I think it couldn't be further from the truth. 
>>
>> Yes, these ain't the wild west days of yore. (Granted)
>>
>> But Django has successfully transitioned (with large thanks to the effort 
>> Tim Graham put in as Fellow over that time) from young to mature and it 
>> still growing. 
>>
>> Even if you take out your favourite headline feature — don't say it :) — 
>> v3.0 is going to be an awesome release. 2.2 was too. And 2.1. And it's 
>> continuing forward. 
>>
>> I wish we'd drop negative self-talk. It lowers morale and isn't even 
>> correct. Django is in great shape, and only getting stronger. 
>>
>> Could we do with more contributors? Yes. So let's do what we can to make 
>> that better. 
>>
>> I think of the effort to move from Trac. Maybe it's worth it... But I 
>> think of the same effort spent improving djangoproject.com, and the How 
>> to contribute guides (I think Tobias said the Contributing docs are 
>> X-thousands of words—all great but not necessarily that approachable), and 
>> so on, and I wonder if it's the best ROI? (That's a genuinely open 
>> question: DRF uses GitHub issues I don't see it leading to any more 
>> engagement there...) 
>>
>> Go Django Go! 
>>
>>
>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ace34012-e5ac-4bbc-ad5b-d3fbac1a560a%40googlegroups.com.

Re: Feedback on Django Channels

[Vincent]

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 <thebe...@gmail.com 
> > 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: Feedback on Django Channels

[Vincent]

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 <thebe...@gmail.com 
> > 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 <thebe...@gmail.com> 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
>>  
>> <https://groups.google.com/d/msgid/django-developers/9ce52a05-88d6-412f-9cfe-59c600c35df7%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-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: Feedback on Django Channels

[Vincent]

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 <thebe...@gmail.com> 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 illustrate

Re: Feedback on Django Channels

[Vincent]

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: Feedback on Django Channels

[Vincent]

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 <thebe...@gmail.com 
> > 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 function

Re: Supported Python versions for Django 1.7

[Vincent]

I agree that there is likely to be little overlap between people using old 
systems and people using bleeding edge Django versions. Along the same lines, 
it's worth noting that these users will have a supported version if Django 
(1.6) for more than a year from today anyway.

Python 2.6 reminds me of IE6 for some reason. My grandpa used to tell us 
stories about Python 2.6 when me and my brothers were kids. He used to talk 
about how someday Python would be really great. He was right. I miss the 80s. 
Anyway, sorry, I'm just reminiscing a bit. 

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

Re: Proposal: better support for generating rest apis in django core

[Vincent]

Huge +1 on everything Tom said, except the point about the docs:

Calling out quality packages in some way from the docs
>

The nice thing about developer communities is that they're fairly emergent. 
Consensus is usually formed all the way from the very bottom, on up. This 
works well.

Especially to a newcomer, an innocuous claim like, "X is a decent library 
for Y" from a well-known framework like Django may as well be, "X is the 
library you need to use for Y". This has the unfortunate effect of creating 
a monopoly, which invariably results in stagnation.

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

Re: contributing to django as a part of master thersis

[Vincent]

+1 on the multi-writes, for what it's worth.

For the type of work I do this would be a tremendous resource saver
(highly transactional, write-heavy, etc). I've always wondered why
Django didn't include this (I'd get off my *** and pitch in, if I were
even half way OK at SQL), but I've also wondered how many developers
there are that use Django for very write-heavy projects. Most of the
projects I've explored are in the CMS / read-heavy / cacheable
category.

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

Re: Feature request - add raw_post to test client

[Vincent]

On second glance, ``Client.post`` does support raw posting ``data`` as
a ``str``, as long as you pass your own ``content_type`` with it. It's
not in the docs, or the method's docstring, but it's easy to do.

On Jan 23, 4:46 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Mon, Jan 17, 2011 at 1:16 AM, Vincent <thebeach...@gmail.com> wrote:
> > When looking through the test client I noticed that it requires a
> > dictionary and always uses multipart/form-data posts. Sometimes it's
> > helpful to use a raw post, instead. The flexibility allows you to just
> > post a string, use key-value pair format, or anything you want,
> > really. Using raw posts wouldn't be suitable for Django's model forms,
> > etc, but one specific example is the JSON-RPC spec which requires a
> > raw post of JSON (instead of key-value pairs or multipart/form-data).
>
> > I could write the code, if this seems like a reasonable addition.
>
> Yes, it seems like a reasonable addition to me. Feel free to open a
> ticket and provide a patch.
>
> Yours,
> Russ Magee %-)

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

Feature request - add raw_post to test client

[Vincent]

When looking through the test client I noticed that it requires a
dictionary and always uses multipart/form-data posts. Sometimes it's
helpful to use a raw post, instead. The flexibility allows you to just
post a string, use key-value pair format, or anything you want,
really. Using raw posts wouldn't be suitable for Django's model forms,
etc, but one specific example is the JSON-RPC spec which requires a
raw post of JSON (instead of key-value pairs or multipart/form-data).

I could write the code, if this seems like a reasonable addition.

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

Getting Images to display in Development Environment

[Vincent]

I am new to Django and Python and trying to learn by going thru an
open source application called Vection. I get everything up and
running except for the static images. I followed the article at
http://www.djangoproject.com/documentation/static_files/ put I still
can't get the images to serve. Could you tell what I am doing wrong?

Enivornment:
Windows using the django web server

Application:
Absolute Path: C:\development\Vection
Code: C:\Development\Vection\vection_01

Image location: C:\Development\vection\media\

Settings.py:
 (I have two, one in C:\Development\vection\ and C:\Development\vection
\vection_01 both match)
MEDIA_ROOT = 'C:/Development/vection/media/'

# URL that handles the media served from MEDIA_ROOT.
# Example: "http://media.lawrence.com;
MEDIA_URL = '/media/'

URLs.py:
#Dev Media Server
 (r'^media/(?P.*)$', 'django.views.static.serve',
{'document_root': 'C:\Development\Vection\media', 'show_indexes':
True}),


URL: http://127.0.01:8000/vection/login/
Image: http://127.0.01:8000/media/images/login/login_tmp_r1_c1.png
(physcial loc: C:\Development\Vection\media\images\login\
login_tmp_r1_c1.png

Thanks for your help!

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---