Re: A Django Async Roadmap

[Tom Christie]

I wonder if a sensible first tack onto this might be:

Supporting an ASGI/asyncio request-response cycle in 2.2 might be a 
perfectly achievable goal with or without funding. Users wouldn't be able 
to  use the ORM, or much of the default middleware, but for some 
gateway-type services I can still see it being useful.

A proof of concept there might help validate (or otherwise) both the 
motivation (run some actually tests against a service that makes outgoing 
HTTP calls and then returns a response - what sort of throughput can we 
achieve there vs. the threaded case?) and the feasibility (what aspects 
that we haven't considered do we bump into along the way to 
implementation?).

Perhaps we could work on the basis of (1) pulling together a proof of 
concept there, and then (2) attempting to get that into the 2.2 alpha 
freeze, without being blocked on getting together the rest of the plan & 
funding for the more substantial parts such as the ORM work?

That wouldn't necessarily preclude also getting asnycio ORM work into 2.2, 
or achieving funding early on, but would at least give us something 
valuable to start working towards immediately?

-- 
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/b994f620-cfb9-4e4c-aac7-c601be809b5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A Django Async Roadmap

[Tom Christie]

> Do we think async is worth going after?

I think this is hugely important. Django's advantage in the field currently 
is in it's developer productivity and maintainability. As frameworks based 
on Node or on languages with co-operative concurrency built-in continue to 
mature it's going to face more of a squeeze there, while being less 
resource efficient than many alternatives.

Although performance characteristics are often over-stated or over-valued, 
it's still a substantive point against a team choosing Django in some 
circumstances. It's particularly relevant in super successful high-scale 
cases, and I want Django to continue to be a great choice both for single 
person building out an MVP on a couple of instances, all the way up to 
large teams working on massive systems, with many running services.

If we don't attempt to tackle this I think we may end up very slowly 
starting to write Django out as a contender for some teams.

> Can we do this in a reasonable timeframe? If not, is there a way around 
that?

I can't speak to the ORM work, as I don't know the internals well enough, 
but I think how everything else is proposed makes sense. The minimal first 
step, of tackling the request/response path is already potentially valuable 
for any teams that include an API gateway as one of their services - being 
able to have a Django-based app that can make non-blocking requests out to 
other services would immediately benefit a decent chunk of real-world use 
cases.

> How should we fund this?

It's a pretty serious amount of funding you'd want to see, so I guess 
ideally not as a single backer.
A joint combination of Mozilla's MOSS program, PSF grant, and corporate 
sponsorships all orchestrated together? (Waves hands magically)
Wrt. corporate sponsorships I think we might well want to set realistic 
expectations about how much developer time money actually buys, and a set a 
decently high minimum tier. What I think works especially well is tying in 
contributions, so. eg. an agreed-in-principle grant that's conditional on 
also achieving a certain amount of corporate sponsorships might be a great 
motivator for companies to make a shared, collaborative investment. ??

Thanks Andrew - *really* exciting proposal.

-- 
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/72d08b8d-06e8-4447-8017-9f3629b43656%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

I've started to address some of the missing documentation aspects for this, 
here... https://github.com/django/django/pull/9072
I'll put in a bit more time tomorrow & friday and aim to make sure that 
it's reviewable by that point.

It's a bit of a tough one to have to review right up against the alpha 
deadline, so it's worth shouting out if there are any other obvious blockers
that'd need resolving before being able to take a call on it.

Cheers all,

  Tom

-- 
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/405bb3a1-cf35-4bbc-8f8f-c930bc0aadc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Rethinking ASGI & Channels

[Tom Christie]

Hi Andrew,

Thanks for writing that up so comprehensively!

Definitely in favor of moving to a server:consumer interface - as you say 
that doesn't preclude over-the-network from being one of the possible 
deployment styles.

I like your proposed approach to async vs sync variants of the interface.

The callable returning a callable is a neat way around too, although I 
can't immediately figure out how eg. middleware looks against that pattern.

Also does the interface look the same for worker:consumer? ie. Is it 
expected that `send()` could either be direct to server, or over a channel 
layer, with the client being agnostic as to which of those two cases will 
be used, or is the client expected to use the channel layer in that case?

Cheers,

  T. :)

-- 
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/4c215111-c060-4ad6-af13-b177bf46c5b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Tom Christie]

Raising this across in aio-libs for a bit of exploratory 
discussion... https://groups.google.com/forum/#!topic/aio-libs/7rJ8Pb1y7aA

> I'm not sure where I sit on it - on one hand <...> on the other hand <...>

Same really, yes. :)

-- 
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/f0d7c10d-101f-4f6b-8620-bc6e2910501a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Tom Christie]

> My ideal solution is one that allows both approaches, and I'd like to 
investigate that further. I think you're getting closer to the sort of 
thing I'm imagining with the uvcorn designs, but I feel like there's still 
something a little extra that could be done so it's possible to offload 
over a network easily (as you mention, letting consumers go to channel 
layers).

Indeed. Centering on the consumer interface doesn't mean that using a 
channel layer isn't an option, just that it's not the base case. It also 
composes really nicely, in the same way as WSGI middleware eg...

app = router({
'http.request': wsgi_adapter(wsgi_app),
'websocket.*': redis_channel_layer(...)
})

>  If we end up with one format for channel names and messages that is 
spread across two consumption forms (in-process async and cross-process 
channel layers), I think that would still be a useful enough standard and 
make a lot more people happy.

Yes. I'm not sure if there aren't also reasonable ways to have standard 
non-asyncio frameworks deployed directly behind a server, too. Personally 
I'm looking at using your work to fill the gap of having no WSGI equivalent 
in the asyncio framework space.

> I wish there was a nicer way to achieve this than having send_async() and 
send_group_async() methods (etc.), but the only other alternative I see is 
having the methods all mirrored on an .async object, as in 
"channel_layer.async.send()". I'm not sure how I feel about that - thoughts?

First thought is that the same issue likely applies to a bunch of the 
extension methods. That's a good argument in favour of keeping the API 
surface area as minimal as possible. I'm still keen on an API that only 
exposes data and channel send/receive primitives (and associated error 
handling), and simply doesn't allow for anything beyond that.

The naming aspect has plenty of bikeshedding potential. My current 
preference probably sounds a little counter-intuitive, in that I'd be happy 
to see synchronous and asyncio version of the interface be two incompatible 
takes on the same underlying interface. ie. name them send() and receive() 
in *both* cases. You don't ever want to expose the sync version to an 
asyncio framework, or vice versa.

Asyncio essentially introduces a language within a language, eg. it 
wouldn't be unreasonable to see an `apython` interpreter in the future, 
that fully replaced all the incompatible parts of the standard library with 
coroutine equivalents, so I wouldn't have a problem with treating it almost 
as two separate language implementations against the same spec. I don't 
think it's worth getting hung up on resolving this aspect just yet tho. 
Less contentious would be at least asking the question "should we treat the 
interface as asyncio-first (eg. send/send_blocking) or sync-first 
(send/send_async)?"

Cheers,

  Tom

-- 
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/0ffcaeca-9066-4351-aebb-11d826e6a215%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Tom Christie]

> I wonder if there is a way of doing something like this well, so that 
it's easy to write but also lets you scale later.

It's not obvious that sticky websockets are *necessarily* problematic for 
typically use cases. Couple of things you'd want:

* Have clients be responsible for graceful reconnects. (This seems like a 
reasonable policy in any case.)
* Have instances enforce a maximum number of concurrent websocket requests 
that they'll accept. (Optionally combined with load-balancing websocket and 
HTTP to different sets of instances.)

A totally different tack would be a websocket load-balancer proxy that 
transparently handles reconnects across the pool of servers, as required. 
It doesn't look like Nginx supports that, but it might not be a ridiculous 
proposal given that it does support acting as a websocket proxy to multiple 
servers.

However what I'd *like* to do would be to write a consumer that routes 
messages to a channel layer. At that point uvicorn would be a fully fledged 
alternative implementation to daphne.

One question there: The channel layer `.send(...)` method is currently a 
regular method. Should there be twisted/asyncio equivalents in the spec? 
Given that I'm writing an asyncio server I'd ideally like to be able to use 
`await channel_layer.send(...)`. (Granted it's only eg. a quick redis hop, 
and I do also have the option of running those operations within a separate 
thread.)

-- 
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/3fe6c9c3-8cd2-4e22-bb0e-82f28355f866%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Tom Christie]

> I note that your examples do not include "receiving messages from a 
WebSocket and sending replies" - I would love to see how you propose to 
tackle this given your current API, and I think it's the missing piece of 
what I understand.

I've just added an `echo` WebSocket example.

I've also now added support for broadcast, currently implemented using 
Redis Pub/Sub.
There's a full example for a chat server that can be properly distributed. 
(*)

Aside: Right now that *happens* to be implemented as middleware, but 
there's no reason it couldn't equally well be integrated at the server 
level, so not a detail to get sidetracked by. More important is how the 
application interface for it looks.

(*) Yes, you'd have sticky WebSockets.

-- 
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/2da48b17-b47f-42e3-b1bb-4a0e5a9b5709%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Tom Christie]

> def handler(channel_layer, channel_name, message):

Oh great! That's not a million miles away from what I'm working towards on 
my side.
Are you planning to eventually introduce something like that as part of the 
ASGI spec?

> So is the channels object just a place to stuff different function 
handlers?

No, it's just a different interface style onto exactly the same set of 
channel send/receive functionality.
It's the difference between this:

def hello_world(channel_layer, channel_name, message):
...
channel_layer.send(message['reply_channel'], response)

And this:

def hello_world(message, channels):
...
channels['reply'].send(response)

> Why not just pass the channel layer there and use the API on that 
directly? e.g.: channel_layer.group_send("chat", message["text"])

With the groups example I wanted to demonstrate that we don't need extra 
"extensions" API introduced onto the channel layer in order to support a 
broadcast interface.

> then frameworks can do per-channel-name dispatch if they like

Yup, the channel name is certainly necessary.
A possible alternative is including that in the message itself, which I 
also quite like as an option because you more naturally end up with a nice 
symmetry of having the signature of the child routes match the signature of 
the parent.

   def app(message, channels):
channel = message['channel']
if channel == 'http.request':
   http_request(message, channels)
elif channel == 'websocket.connect':
   websocket_connect(message, channels)
elif ...

That's what I'm rolling with for the moment, but it's not something I'm 
necessarily wedded to.

I've done a bunch more work towards all this, so it'd worth checking out 
https://github.com/tomchristie/uvicorn in it's current state. That should 
make the interface style I'm considering more clear. (Focusing on asyncio 
there, but could equally present an equivalent-but-syncronous interface.)

There are also now initial implementations for both WSGI-to-ASGI and 
ASGI-to-WSGI adapters.

Thanks!

  - Tom :)

-- 
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/66b90b7f-c76d-4d2b-aa20-4b04aa188e5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Tom Christie]

Figure I may as well show the sort of thing I'm thinking wrt. a more 
constrained consumer callable interface...

* A callable, taking two arguments, 'message' & 'channels'
* Message being JSON-serializable python primitives.
* Channels being a dictionary of str:channel
* Channel instances expose `.send()`, `.receive()` and `.name` interfaces.

Extensions such as groups/statistics/flush would get expressed instead as 
channel interfaces,
eg. a chat example...

def ws_connected(message, channels):
channels['reply'].send({'accept': True})
channels['groups'].send({
'group': 'chat',
'add': channels['reply'].name
})

def ws_receive(message, channels):
channels['groups'].send({
'group': 'chat',
'send': message['text']
})

def ws_disconnect(message, channels):
channels['groups'].send({
'group': 'chat',
'discard': channels['reply'].name
})

My thinking at the moment is that there isn't any great way of supporting 
both asyncio and sync implementations under the same interface.
If you're in asyncio land, it makes sense to *only* expose awaitable 
channel operations as you don't ever want to be able to block the task pool.

I think the best you can really do is express two distinct modes of 
interface.

sync: (callable interface, blocking send/receive interface)
asyncio (coroutine interface, coroutine send/receive interface)

Presumably the equivalent would be true of eg. twisted.

(There's a couple of diff things you can do to bridge from the asyncio 
interface -> sync interface if that's useful)

-- 
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/c6cb3dc6-7c30-4eca-a389-326552ca4c36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Tom Christie]

> Any interface like this would literally just be "this function gets 
called with every event, but you can't listen for events on your own"

Gotcha, yes. Although that wouldn't be the case with asyncio frameworks, 
since the channel reader would be a coroutine.
Which makes for interesting design thinking if you want to provide an 
consumer interface that's suitable for both framework styles.

> HTTP request bodies being not an event, but a stream, and they're fine as 
they are deliberately on a special channel per request. 

Which it turns out actually makes the cooperative-tasks in a single-process 
implementation slightly awkward. (Doable, but rather more complex)
For the purposes of my implementation it makes sense that if you've got a 
synchronous HTTP callable, then the server should buffer the incoming data
and only dispatch a single message. (Not a problem wrt. Django, since 
ASGIHandler ends up effectively doing that in any case.)

Anyways, thanks for talking through all this - it's been immensely helpful!

  - T :)

-- 
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/09684194-cc32-41c1-8073-7838c468c938%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Tom Christie]

Making some more progress - https://github.com/tomchristie/uvicorn
I'll look into adding streaming HTTP request bodies next, and then into 
adding a websocket protocol.

I see that the consumer interface is part of the channels API reference, 
rather than part of the ASGI spec.
Is the plan to eventually include the consumer interface as part of the 
ASGI spec, and make it more clearly separate to channels?

> The ability to just plug in a callable/coroutine that gets called with 
messages as they arrive, and which provides you with channel names to 
listen on as an attribute

This sort of interface is exactly what I'm looking for, yes. From my POV 
the consumer callable is the primary bit of interface, rather than the 
channel layers.

The consumer interface as it currently stands *is* sufficient for writing 
alternative frameworks against, but it's possible that there could be a 
more limited, refined interface to be had here. (Eg. limiting the message 
argument to being something that contains only serializable data and 
channel interfaces.)

What would be great would be to have *just* the ASGI consumer callable 
interface pulled into Django core, and have channels be one of the possible 
ways of deploying against that.

> persist state somewhere outside the locals() of the function (as you'll 
still have separate coroutines for connect/receive/disconnect).

I assume you'd use the name of the reply_channel as the key to the state 
there, right?

Incidentally asyncio implementations have less of a requirement here, as 
you could write a single coroutine handler that's called on `connect`,
and that can then can non-blocking reads to a channel for incoming data, 
and could support broadcast via an asyncio interface onto redis pub/sub.

Cheers,

  Tom :)

-- 
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/02d36ad5-a41e-48e2-8ce0-1e5c64e4eea5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Tom Christie]

> I suspect there is potential for a very fast async-only layer that can 
trigger the await that's hanging in a receive_async() directly from a 
send() to a related channel, rather than sticking it onto a memory location 
and waiting

Yup. Something that the gunicorn worker doesn't currently provide is 
`receive()/receive_async()` hooks, and instead current just  rely on 
`send()`ing every incoming message. For eg. HTTP the one thing that doesn't 
give you so easily is request body buffering or streaming, but you *could* 
handle that on the application side if you really wanted.

I think that the sensible next step for me will be to work towards adding 
that interface in, at which point we ought to have an implementation 
capable of running a Django service using ASGIHandler. (And yeah, I see 
that you'd be adding channel queues at that point.) ayncio.Queue is looking 
like a mightily useful bit of tooling right now.

> the design of an ASGI-direct protocol

I think the important part of this is "how does asyncio code look in the 
context of an ASGI consumer interface" rather than specifics about 
server-direct-to-consumer configurations. Not unreasonable that an "An 
asyncio ASGI app, running behind a full channel layer" could be a thing 
too, in the future.

Perhaps a good way of narrowing this down would be to consider an asyncio 
runworker: Is the application responsible for pushing coroutines onto the 
event loop (advantage: more narrowly scoped), or do you extend the ASGI 
consumer callable definition to also allow it to be a coroutine 
(advantages: more natural interface, server can manage task cancellations).

-- 
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/16f87149-6896-40a2-a1fd-028446a171a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On ASGI...

[Tom Christie]

I've been doing some initial work on a Gunicorn worker process that 
interfaces with an ASGI consumer callable, rather than a WSGI callable.

https://github.com/tomchristie/asgiworker

In the standard channels setup, the application is run behind a message 
bus...

Protocol Server -> Channels <- Worker Process -> ASGI Consumer

In the Gunicorn worker implementation above, we're instead calling the 
consumer interface directly...

Protocol Server -> ASGI Consumer

There's a few things that're promising here...

1. The ASGI consumer interface is suitable for async application 
frameworks, where WSGI necessarily can't be.

In WSGI the response gets returned when the callable returns, you can't 
queue an asynchronous task to perform some work later.
With an ASGI consumer, the messaging interface style means that you can 
push tasks onto the event loop and return immediately.
In short, you can use async...await under ASGI.

2. The uvloop and httptools implementations are seriously speedy.

For comparative purposes, plaintext hello world servers against a few 
different implementations on my MacBook Air

wrk -d20s -t10 -c200 http://127.0.0.1:8080/

  Throughput Latency (stddev)
Go  44,000 req/s 6ms  92%
uvloop+httptools, ASGI  33,000 req/s 6ms  67% 
meinheld, WSGI  16,000 req/s12ms  91%
Node 9,000 req/s22ms  91%

As application developers those baselines aren't typically a priority, but 
if we want Python web frameworks to be able to nail the same kind of 
services that node and go currently excel in, then having both async 
support, and a low framework overhead *is* important.

It's not immediately clear to me if any of this is interesting to Django 
land directly or not. The synchronous nature of the framework means that 
having the separation of async application servers, and synchronous workers 
behind a channel layer makes a lot of sense. Tho you could perfectly well 
run a regular HTTP Django application on top of this implementation 
(replacing wsgi.py with an asgi.py that uses ASGIHandler) and be no worse 
off for it. (Sure you're running blocking operations while running in the 
context of an event loop, but that's no worse than running blocking 
operations in a standard WSGI configuration)

However it is valuable if you want to be able to write HTTP frameworks that 
support async...await, or if you want to support websockets and don't 
require the kinds of broadcast functionality that adding a channel layer 
provides for.

---

At the moment I'm working against the ASGI consumer interface as it's 
currently specified. There's a few things that I'm interested in next:

1. If there'd be any sense in mandating that the ASGI callable *may* be a 
coroutine. (requiring an asyncio worker or server implementation)
2. If there'd be any sense in including `.loop` as either a mandatory or as 
an optional attribute on a channel layer that supports the syncio extension.
3. Andrew's mentioned that he's been considering an alternative that maps 
more simply onto WSGI, I'd really like to see what he's thinking there.
4. Response streaming isn't a problem - you can send multiple message back 
to the channel, and run that off the event loop. However, I've not quite 
got my head around how you handle streaming request bodies, or around how 
you'd invert the interface so that from the application perspective there's 
something like an interface available for  `chunk = await body.read()`.
5. One other avenue of interest here might be if it's worth considering 
bringing ASGIHandler out of channels and into Django core, so that we can 
expose either an asgi consumer callable or a wsgi callable interface to 
Django, with `runworker` being only one of a number of possible ASGI 
deployments.

Plenty to unpack here, feedback on any aspects most welcome!

Cheers,

  T :)

-- 
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/db158350-60a9-4950-b11c-83f2f7a9221c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

> Some positive yes/no on whether or not this is an actual desirable 
feature for Django from the core team.

We've positive feedback from at least Jacob, Ola, Aymeric, and myself, so 
I'd broadly assume we're good there, so long as there's not any specific 
blockers that emerge.

I'd expect there could(?) end up being some awkward aspects in consensus 
around how we approach the documentation, but we'll see how that progresses.

-- 
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/d85cb679-ade9-48a7-a8c4-753d7fcf871f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

> I'm trusting that they ask for help if there's something the community 
can do.

Personally I've got other priorities at the moment, so it's not something 
I'm working on or looking at.
I do think it's a really nice bit of low hanging fruit tho, just needs 
someone to do a bit of work on shepherding it through.

-- 
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/23120ff4-7771-4e09-91ee-994fd73b1069%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.11 release blockers

[Tom Christie]

> 
this feature https://github.com/django/django/pull/7482 will also be a very 
good inclusion.

Can't see simplified URL routing being complete before the feature freeze. What 
might be feasible is getting the URL kwarg type conversion basics in, so that 
it can fully exist as a third party package, with full support slated for 2.0.

-- 
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/c8dc3d6e-3bde-4518-bbb4-4aac0c8f2eaa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider reverting or adding guidelines on how to use class based views for security sensitive features

[Tom Christie]

Just to be absolutely clear, in case it's needed...

> is to hold off the deprecation of the function-based views.

Markus is specifically referring to the FBV implementations of the 
contrib.auth views here.
(Not to FBVs generally, which we've no intention of deprecating whatsoever)

  - Tom

>

-- 
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/ee70f431-412d-45ee-b646-37adb1d1f464%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

> What is the current status of this pre-proposal?

I think it's ready for some initial work to validate the approach.
I've got some time available for this in the near future, given that I'm 
currently on open source work full time 
.

> Is there anything I can help with?
If you also wanted to get involved I'd suggest considering:

A PR for the DEP, taking it from the current markdown Gist, into a properly 
formatted Rst document.
A PR for any of the implementation tasks listed (all fairly separate pieces 
of work) to get things moving. (Things may still change once the DEP starts 
to be fully reviewed, but there's no great harm in getting started.)

Cheers,

  Tom

-- 
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/50b149c9-6a28-4f88-9690-1a5b291a72ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

> an option could be to target this for inclusion in Django 2.0 but make 
the necessary fixes in Django 1.11 to allow this to exist as a third-party 
app in the meantime.

Interesting idea, yup. I'm open minded at this stage.
Other hurdles to get past first, so let's see how we go before calling a 
judgement in that. Certainly worth having as an option.

> You can list me as the DEP shepherd if needed.

Grand. Let's run with that then, unless anyone else (from the core team) 
particularly wants to step up.

Thanks,

Tom

-- 
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/15d5c484-bf05-4690-bf04-b15faad2bf6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

> wondered if it'd be possible here to get rid of the converter in the 
syntax at all, or have a default one if none is provided.

Actually yes, I'd not noted in the proposal but you can also simply use eg.

path('users//')

By default that'll give you the 'string' convertor. (Accepts any text 
without a slash.)

I've updated the document to reflect this.

-- 
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/e62c279f-4f0b-4cbc-9f98-36650407835e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

I've iterated on the pre-proposal, with what I think represents the best 
options to date.

https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98

The updates are:

* Using a different name for the syntax: `path()`.
* Dropping the leading slashes.
* Simplifying the "unintended errors" section.

At some point I'll likely start working towards a validation of this. 
(Other takers also most welcome.)
If/when we decided to submit a draft DEP for more in-depth review & 
consideration, we'll need a shepherd for the proposal. Any takers? (Must be 
someone from the core team, with commit access.)

Cheers all,

  Tom

-- 
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/96e7d90b-e917-40d5-a883-734872724456%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

Yup, good points there. I wasn't really considering `include` at that point.

Definitely some awkwardnesses that need thinking about there.

urlpatterns = [
path('', homepage),
path('users/', users_list)
]

Looks very odd to me, since those are not actually valid URL paths. ('/' 
and '/users/' are the actual URL paths)

Anyways, something to mull over. That and the import names are probably the 
two areas that'll need resolutions.

-- 
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/70d64bf4-6ba9-444f-b161-165e6607d257%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

> About the url convention

We're not changing anything about the URL conventions, we're changing the 
oath syntax.
Django tends to use a trailing slash style by convention. This proposal 
wouldn't change that in any way.

> The only technical reason I see for enforcing the starting slash

The leading slash in the syntax is open to discussion, however I'm very 
strongly in favor due to two points:

* It is a strong and consistent visual indicator.
* Doing so would mean that Django and Flask share exactly the same routing 
syntax. (Flask enforces a leading slash)

I think there are *very* strong reasons to have a single consistent URL 
syntax used across the two most popular Python web frameworks.
This is a new syntax, and the capture groups have changed substantially, so 
I think it's acceptable that it also doesn't happen to echo the regex style 
wrt this particular aspect.

> The question about the old routing system is about the plan to build on 
top the old one.

There's nothing to stop a current or later proposal for redesigning the URL 
system in order to provide for non-path based routing. That's a different 
conversation. Nor is there anything to stop either an internal refactoring, 
or an alternate proposal for how to implement the described syntax. Design 
proposals or PRs welcome.

-- 
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/4011b577-4ce8-4f1f-8c04-027d5b9cc8b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

Some possibilities:

1. Use a different name for the new function.

path('/users//')

Actually `path` is pretty valid as a name there - that's *exactly* what it 
represents - the path portion of the URL.
Alternately `route`?

2. Keep `url` for both styles, but with a really simple determination 
between regexs/typed urls.

The pattern *must* start with either `^` or `/`.  (Include a 
`regex_url` and `typed_url` for the explicit cases)

3. As per (2) but additionally have the usage of regexs in `url(...)` be 
placed on the deprecation path.

I think (1) is probably my favorite choice of those, but I'm open to 
discussion.
That'd give us `from django.conf import path`, and `from django.conf import 
regex_path`. The existing `from django.conf.urls import url` would keep the 
existing behavior but move towards deprecation.

I'm very strongly in favor of keeping Flask's style for "".
Considering the wider ecosystem, the choice between having Python's two 
biggest web frameworks share the same routing syntax vs. having them share 
subtly different syntaxes is pretty clear.
I think that's a far bigger concern that if the routing syntax echos 
Python's type hinting syntax or not.

To me, the alternative reads like this:

A: "Hey folks! Django's got a new routing sytnax!"
B: "Great what's it like?"
A: "Exactly the same as Flask. Oh, but we've reversed two of the arguments 
around."
B: "Uh, WTF?"

Cheers for the input everyone,

  Tom

-- 
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/7550dd77-ef22-4b92-b42e-aad6116ffc84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

Okay then, I've made some updates:

* Updated the import design, in line with Jacob's suggestion.
* Brief note on URL conventions, and the leading '/'.
* Section on guarding against errors between `from django.conf.urls import 
url` and `from django.urls import url`.
* Brief note on the internal RegexURLPattern API.
* Breakout of required implementation tasks.

 Also, wrt Ryan's suggestion of reversing the ordering of name and type: 
I've some sympathy towards it, but I believe that presenting a consistent 
API between both Flask and Django is a more important factor.

Cheers all,

  Tom

-- 
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/6a75cb7d-6df2-45e7-8efe-6c2f0526cfbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

> My suggestion is that we move towards `url()` giving "new style" patterns

Agreed. I couldn't see a nice way around to do that, but moving the import 
to `from django.urls import url` sidesteps the issue nicely.
Sounds good to me.

-- 
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/5384cbd3-5873-4532-9a0f-9963d20d13dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

> There's text that elaborates on how to detect which one of the two 
options is implied. I'd recommend making that a section in and of itself.

Probably a good plan, yup. I was somewhat writing that section as I 
thought, so it comes out a bit jumbled. I'm more confident in retrospect 
that regex vs typed detection is a reasonable approach. I can't see any 
obvious problems there that I'm missing. I'll take another pass at that in 
due course.

> The DEP states that the new routing will be implemented in terms of the 
existing regex based system. Could you add a note here stating that that's 
merely an implementation detail?

Yup - I've done a bit of re-wording in order to try to clear that up.

Thanks!

-- 
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/ea247b0b-bc49-4de4-86d1-9cd765c0f42b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

Hi folks,

I wanted to push forward the consideration of introducing a simpler URLs 
syntax, plus support for URL parameter type conversion.

A pre-proposal is available here: 
https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98

At this point I'm seeking feedback, before hopefully iterating on the 
proposal, and making a formal submission.

I'm not making any assumptions right now about where this might get too, or 
who'd be involved if it does make it to the DEP stage, and would very much 
welcome outside involvement. I'm also aware that while there's been some 
positive reception, it's not yet clear if we'll reach a consensus on 
inclusion in core.

Personally I'm very firmly +1 on this, as I feel that the existing syntax 
is a rather glaring and unnecessary pain point.

Thanks to everyone who's started to kick this off, in particular Emil 
Stenström for raising the original thread, and Sjoerd Job Postmus for their 
work on the Django Simple URL 
 package.

  - Tom

-- 
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/1450171a-be2b-41e8-b221-91bfe656d039%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Tom Christie]

Wanted to add my support for this.
Personally I'd be totally in favour of considering something along these 
lines for core, once there's a fully proven design.

The capture syntax is:

* Far simpler.
* Meets pretty much every single real-world case I ever see.
* Gives us type coercion.
* Also able to support regex fragments if needed. Eg see 
http://stackoverflow.com/questions/5870188/does-flask-support-regular-expressions-in-its-url-routing

Given that we could continue to keep the existing style around as well, 
this is an area where I'd be happy to see Django take a step forward.

Sticking with the path->existing regex mapping implementation sounds like 
the best tack, at least initially, rather than getting bogged down in API 
discussions around how we'd tackle a routing API if we wanted to support 
non-path routing.

Cheers,

  Tom

-- 
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/9a0ee2a3-37bc-4b4d-83e3-a2a1b6cf34e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: should blank POST data fallback to use model field defaults?

[Tom Christie]

It's not perfect but given that it's an inherent limitation of HTML checkboxes, 
I don't think that documenting that limitation is that big a deal.

forms.BooleanField(required=False) feels like an odd combination to me in any 
case. One way we could potentially help users would be to error in that case 
unless an alternate widget is used (We could recommend select or whatever it is 
we use for NullBooleanField in this case)

We have the same issue in REST framework serializers FWIW. As with Django<1.10 
we treat omission as omission, not blank. And yes, we have to special-case 
boolean omission.

-- 
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/14856bb1-9c31-42a5-8f16-e8da8222b09d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Tom Christie]

I'd always defer towards humanized limits, rather than technical limits, so 
I'd suggest 100 chars seems like a decent cap.

-- 
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/1f6ca1c4-da49-44b3-869a-f799e04567c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

[Tom Christie]

> a consensus on how to proceed here might be useful for documenting best 
practices as other apps run into similar troubles.

I guess I'd suggest...

Most realistic in immediate future: Accept it as a current limitation 
(possibly handle TooManyFieldsSent)
Someday later, perhaps: Allow a "select everything" that does not use 
individual POST fields 

Also, I don't recall if we allow users to turn the behavior off or not?

-- 
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/81071b43-64ef-43f3-9d16-bb2e65f6465e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Call for Channels work

[Tom Christie]

> if you can work on drafting a call that would be great

Sure, sounds like a sensible place to start.
I won't get onto anything immediately, but I'll start to have a think about 
spec'ing it out at some point.

(Other offers/progress on this from anyone also welcome in the meantime 
tho')

> Why would this write you out of pitching for it, though?

Yes, fair point.

  - Tom

-- 
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/19d8ca9f-723b-4374-add6-81ede20312e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Call for Channels work

[Tom Christie]

> we don't have a mechanism to delegate the "what should we build" part of 
the question for work other than channels.

I guess there's two aspects to that.

1. Do Mozilla allow some flex in meeting the proposal / do we have an 
differing priorities now / do we want to discuss what those should be?
2. Breaking down request parsing/response rendering, as initially described 
in the proposal, into a call for work. (Assuming we do want to include it?)

Given the release timelines I don't think we're in any great rush to make 
decisions here - 1.11 isn't due til April '17.

Couple of options:

* Plan to make a firm decision at the core team meeting in Django Under the 
Hood, having solicited feedback more widely first?
* I could take on drafting up a call for work on the request/response 
portion. If there's a strong applicant for it, then we'd have plenty of 
time for it to start making its way in, without being remotely up against 
an alpha release deadline. (That way around would rather write me out of 
being an applicant, but might work well if we get the right person on 
board, and there might be scope for an a review/advisory role from Tim or 
myself)

No firm opinions at this point, myself.

  Tom

-- 
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/c5e5e0e0-894d-4580-9a1a-2fa9267e334b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Call for Channels work

[Tom Christie]

Do the Django MOSS committee have any plans for the request 
parsing/response rendering portion of the Django MOSS proposal?

I'm assuming that any of the following could be reasonable choices:

* Expecting to issue a call for work in due course, but treating channels 
as the priority for now.
* Defer any decisions on it until the channels portion is deemed 
sufficiently complete.
* Decide that it's no longer regarded as a priority and use the resource 
elsewhere.
* Decide that it would conflict with the REST framework MOSS grant and use 
the resource elsewhere.

Asking more from a stand-point of transparency, than trying to push for a 
'call for work' to be issued.
Personally, the second option on that list probably sounds like the best 
overall choice at the moment, but I think any could be valid.

Cheers,

  Tom

-- 
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/f1b3bf18-b8dd-49c9-8b34-9125a2ff9d6e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Some thoughts on upgrade pain & deprecations.

[Tom Christie]

Picking this up in trac: https://code.djangoproject.com/ticket/26713
And github: https://github.com/django/django/pull/6732

On Thursday, 2 June 2016 16:00:26 UTC+1, Tom Christie wrote:
>
> > I'm against adding custom behavior in Django
>
> That's entirely reasonable, yes.
>
> In which case, what do folks think of the following suggestions:
>
> * Linking prominently to the 'upgrading django 
> <https://docs.djangoproject.com/en/dev/howto/upgrade-version/>' section 
> from at the begining of every new version's release notes.
> * Tweaking the upgrading django section so that it recommends *first* 
> running your existing test case with warnings enabled and resolving those 
> at that point, *before* upgrading django, and *then* upgrading and running 
> the tests again, at which point you don't necessarily need warnings 
> enabled. (As it currently stands it's rather the wrong way around)
> * Tweaking the upgrading django section so that it also mentions making 
> sure that your test runner isn't silencing the warning output. (eg "Using 
> the py.test runner, you probably want to use something like 
> `PYTHONWARNINGS=default py.test tests -s`")
>
> Cheers,
>
>   Tom
>
>

-- 
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/e4a231d6-32ee-4902-9059-69af87cc5b3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Some thoughts on upgrade pain & deprecations.

[Tom Christie]

> I'm against adding custom behavior in Django

That's entirely reasonable, yes.

In which case, what do folks think of the following suggestions:

* Linking prominently to the 'upgrading django 
' section 
from at the begining of every new version's release notes.
* Tweaking the upgrading django section so that it recommends *first* 
running your existing test case with warnings enabled and resolving those 
at that point, *before* upgrading django, and *then* upgrading and running 
the tests again, at which point you don't necessarily need warnings 
enabled. (As it currently stands it's rather the wrong way around)
* Tweaking the upgrading django section so that it also mentions making 
sure that your test runner isn't silencing the warning output. (eg "Using 
the py.test runner, you probably want to use something like 
`PYTHONWARNINGS=default py.test tests -s`")

Cheers,

  Tom

-- 
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/88cc77e2-fe2b-480d-8378-9fbd33e7745a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Some thoughts on upgrade pain & deprecations.

[Tom Christie]

The low tech solution to this, may just be to have the release notes 
recommend running your test suite using
`PYTHONWARNINGS=once`, and making sure not to swallow any output, eg. with 
py.test that'd be...

PYTHONWARNINGS=once py.test tests -s


I'm fairly sure that making that point explicitly would save an awful lot 
of folks a more painful upgrade, by making it more clear how to see 
upcoming issues without getting bitten by them and having to debug without 
the help of an associated warning.

-- 
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/c23e2934-b929-41b5-b3d4-572f0be8a66f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Some thoughts on upgrade pain & deprecations.

[Tom Christie]

I've just finished upgrading Django REST framework to support 1.10, and 
it's given me some food for thought on things that can make Django upgrades 
painful.

Firstly, here's a couple of things that I needed to track down in order to 
upgrade that weren't obvious at first...

* A bunch of test views started returning 404s.
* None of the app templates were being found.
* `user` was no longer being passed into template contexts.

All of these were due to changes that have been part of the standard 
deprecation cycle, which is fair enough, however they weren't necessarily 
all that easy to debug. Figuring them out involves digging through the set 
of removed features 
, 
and trying to figure out which of those would result in the behavior change 
that's been seen.

Aside: I think the `.urls = ...` -> `@override_settings(ROOT_URLCONF=...)` 
change to test cases is missing from those notes?

I expected to have seen a deprecation warning when running the tests under 
1.9, although wasn't exactly sure if and when those warnings would be 
displayed.

Seeing the deprecation warnings under 1.9 would have made the upgrade far 
simpler, as I'd be warned about the changes I needed to make, rather than 
seeing a behavioral change and having to debug what might have caused it.

Figuring out how to ensure that the tests properly displayed deprecation 
warnings (under py.test) wasn't all that easy either, eventually I got 
there with...

   python -Wd [...]/py.test tests/ -s

(The behavior still isn't ideal then as each instance of warning is output 
once every time for each occurrence, rather than once and once only)

The upshot of all this is that I believe many of our users are likely to be 
hitting problems with upgrades because they're not seeing deprecation 
warnings, and then get hit by a behavioral change that they weren't 
expecting to have to deal with, and end up having to debug the cause of.

I'm wondering if we could do more to help our users here?

For instance, a user is running under 1.9 and wants to upgrade to 1.10. 
Could we have a reliable and documented mechanism by which they'd first run 
the tests under 1.9, and have any Deprecation warnings treated as errors?

If they're running 1.8, could we document how to run the tests so that any 
PendingDeprecation warnings are treated as errors?

Could we collate instances of these warnings, rather than displaying them 
in an overly verbose fashion?

python -Werror sort of achieves this, but doesn't differentiate between 
deprecation and pending deprecation.

An example of the sort of thing we could do might be to have an environment 
variable `DJANGO_UPGRADE`, that if set to a version number, forces the 
relevant class of deprecation / pending deprecation warnings to be written 
to a log file or similar. I don't think that interface is quite right, but 
suggesting it as an example of how we might make our user's lives easier.

Any other suggestions or thoughts in this area?

  Tom


-- 
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/dd7a2cda-12fd-42e4-8ecb-cfec60c1d69f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Rewriting admin internals

[Tom Christie]

> I also think that working on existing outstanding ticket first and trying 
to solve issues incrementally would be a good approach?

Absolutely, yes. There's plenty of good work that can be done there.

-- 
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/4fd73545-941e-42e8-acaf-4c4979522bd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Rewriting admin internals

[Tom Christie]

> But for the money I don't have any initial source to manage It.

Jacob is using the figure more to give an idea of the amount of effort he 
believes it would involve, rather than suggesting that we should make a 
serious attempt to raise that amount of money.

> can you guide/ show me any previous work/discussion/technical specs etc?

I'd search for DjangoCon and Django Under the Hood videos if you want to 
find some technical discussions on the subject.

Searching through outstanding django tickets related to the admin and 
attempting to fully understand them would also be a good way of learning 
about what pain points exist with the admin.

> I would like to hear from core members about the works right directions

I'd suggest that a side-project of redesigning the Django Admin from 
scratch isn't a realistic goal.

-- 
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/5b69d6bd-f02c-4d93-9f91-ec2c57748a32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Testing pre-release Django

[Tom Christie]

> I'd be curious to hear from any third-party package maintainers how they 
feel about it.

I've not found testing against master to be particularly helpful, as it's 
not apparent if an issue is substantial or not, without putting in work.

The alpha releases *are* tremendously helpful for having a pre-release to 
start working against,
although I don't know what a good process is for feeding back between third 
party packages that are updating, and the Django team.

For what it's worth, I'm seeing a surprising number of test failures 
 for REST 
framework against 1.10a, although I suspect that may will be simple enough 
to resolve.

Another thing that might help is some guidance on ensuring that travis 
builds are properly displaying pending deprecation warnings - that'd go 
some way towards helping package maintainers get ready for a new release 
before it lands.

-- 
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/65364570-3763-499f-a12b-f4102c5f1c6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Withdrawing Channels from 1.10

[Tom Christie]

Seems sensible. In particular having the documentation available as part of the 
regular Django docs would mean there's very little difference to the end user, 
but without us having to get everything merged into the core codebase. Is the 
docs element something we can reach a consensus on, or are there any objections 
to that approach?

-- 
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/babd844f-492a-4e72-8e56-fd1604b02d5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Tom Christie]

> The notion that I would now have to use a data store to run my app at all 
didn't feel right

Fortunately, you don't need to. From the docs in the pull request... "It's 
an optional part of Django; you don't need to interact with it if you're 
just writing a normal website, but if you want the features, you can just 
turn it on."

This isn't comparable to third-party packages, because it's a foundational 
aspect of the framework. Channels making its way into core is advantageous 
in a way that isn't nearly as true for other kinds of features.

> Political tirade follows

I don't think that discussion is likely to be a productive route to go 
down. Everyone here is motivated by the same desire to make Django be the 
best thing it can be. :)

-- 
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/df8906f9-d4ea-41b2-b2c5-57e500a1f01d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Tom Christie]

My preference would be to shift the alpha deadline *without* yet making a 
firm decision on if channels hits 1.10 or not. That would take a little 
pressure off, and not force anyone into making a decision prematurely.

Moving the window back (say 3 weeks?) and allowing a little more time for 
the DEP and design discussion around it, sounds preferable to making a 
rushed judgement in either direction.

Cheers

  - Tom

-- 
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/7ab212b4-340d-41f3-a560-61831a9918e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

[Tom Christie]

> If you are using django-rest-framework, how would the fields counter 
work?. It would be a shame if only multi part and urlencoded uploads would 
have the benefit of these checks, while still allowing json, xml and others 
still be "exploited".
Note I didn't really read the code changes completely so I'm talking with 
almost no knowledge on the proposed change.

They wouldn't be respected by anything other than multi-part or urlencoded 
requests.
Tim's correct in noting that accessing `request.body` or `request.stream` 
won't apply these checks (which is for example, what REST framework does).

Even so I think this is probably a reasonable approach. We could add 
support for respecting these settings in REST framework too, once they 
exist.(Although I think we'd have need to have a stricter consideration of 
backwards compat wrt. folks POSTing large amounts of JSON data)

-- 
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/b78c3cef-60ae-481d-9217-3b9b40eb176e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: JsonpResponse subclass of HttpResponse helps easily create JSONP-encoded responses.

[Tom Christie]

JSONP is essentially a browser hack.
There have been security issues raised around it, and we I don't believe we 
should encourage its usage by including it in Django core.
(If anything we *might?* want to consider CORS for built-in support at some 
point.)
I'd agree with Florian here - I'd rather see this as either a third party 
package, a code snippet that's shared on a blog post, or similar.

  - Tom

-- 
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/37f473d0-8654-4774-82aa-adaf23ea49ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending JSONField serialization

[Tom Christie]

Customizing the encoder (or even using DjangoJSONEncoder by default) isn't 
so bad.

I'm less convinced about the usefulness of customizing the decoder - once 
you've encoded the data into JSON any additional type information is lost, 
so casting back to python primitives is always going to need to be handled 
explicitly.

Being able to set field values that contain eg datetimes *could* be a 
useful shortcut, but it only makes sense to me if we make it clear that 
values passed into the JSON field will only ever be stored/retrieved as 
their JSON primitive representations.

Cheers,

  Tom

-- 
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/3fe79e25-bbab-484a-abd5-051e60fcc189%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Extending JSONField serialization

[Tom Christie]

> Should JSONField accept additional kwargs to customize the encoder and the 
> decoder?

Quick take here:

That sounds like a bit too much "cleverness" to me. The most obvious issue it'd 
cause is putting values of one type into the field, but getting objects of a 
different type back. (eg datetime getting coerced into a string on the way in, 
and left as a string on the way out).
I'd rather see the field closely map to what the underlying database field 
*actually* provides. 

-- 
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/ff5892dd-a4bd-43c7-af80-1c25260873d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: is_authenticated as property

[Tom Christie]

> My own opinion is that if you don't have tests to catch the mistake in 
the first place, you're doing it wrong.

Not sure I'd necessarily agree there - easy to miss the anonymous case.

No obvious best thing to do tho'.

On the one hand it's too easy to get wrong, on the other the current visual 
distinction between the model fields, and model methods may be helpful.

-- 
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/cae9c6ce-57bb-43de-961a-5f5b86ae776b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Report - November 28, 2015

[Tom Christie]

Hi Edwar,

Commenting on the ticket itself would be more appropriate. Also note 
that the ticket's only been open 5 days - I'd suggest a little more 
patience might be needed :)

  T.

-- 
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/3c0b854e-7caa-4540-aa64-056fe4115f59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow impossible model validation (mainly admin and generic forms)

[Tom Christie]

> Append form's non_field_errors with message like

Given that the IntegrityError doesn't occur until the point of .save(), 
it's not obvious how that'd work in terms of the Forms API.
You're absolutely correct that there's a class of constraints that can fail 
here, but it's not evident to me that dealing with these explicitly when 
required (in practice, fairly rare) isn't a better tack.

-- 
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/96d28748-5c24-4448-a83a-f0ac51a30946%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why passing request, *args, **kwargs in dispatch method for generic views

[Tom Christie]

Although those variables are available in both places I'd prefer to see 
them passed explicitly.
That will tend to nudge users slightly more towards passing variable around 
explicitly and slightly away from storing state on the view instance (which 
can be a bit of a gnarly practice - harder to follow the flow of where and 
when some piece of information is actually being used/modified)

On Friday, 23 October 2015 14:03:17 UTC+1, Tim Graham wrote:
>
> It looks like setting the request/args/kwargs attributes came after the 
> original CBGV implementation. 
>
> https://github.com/django/django/commit/ea6b95db
> https://code.djangoproject.com/ticket/19316
> https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion
>
> I haven't looked closely to see if your proposal might cause problems (you 
> could give it a try and see if you can get the Django test suite passing), 
> however, changing the signature of those methods would require a 
> deprecation path and could result in a lot of churn in user code which 
> would probably cause some angst. I'll leave it to users of CGGVs to offer 
> an opinion on whether or not it could be worthwhile.
>
> On Friday, October 23, 2015 at 5:51:37 AM UTC-4, Dheerendra Rathor wrote:
>>
>> Hello all,
>>
>> With reference to this line: 
>> https://github.com/django/django/blob/master/django/views/generic/base.py#L61
>>  
>> from django.view.generic.base
>> before calling self.dispatch request, args and kwargs attributes have 
>> been added to self. So these all are available in self in http_method 
>> handlers. 
>>
>> I think this behaviour is present due to old functional views, but now 
>> passing these as arguments to http_method handlers look obsolete.
>>
>> We can potentially remove these and make http handlers more simple just 
>> like
>> class CustomView(View):
>> def get(self):
>> request =self.request
>> # code ...
>>
>>
>>
>>

-- 
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/6fe6b37d-8ab6-4c66-b036-db480547c4fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Tom Christie]

I'm with Tom here.
Forcing `max_length` to always be set on CharField feels like the right 
decision. Having a default there seems unnecessary obscure, and more likely 
to lead to untested/unnoticed failure cases.
It *could* be that we'd allow `max_length=None` to explicitly turn off the 
validation, but I'm not sure if that's better than forcing developers who 
want unvalidated lengths to use TextField.

-- 
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/dc97b2d7-870e-4952-b08e-428eaf250844%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.9 release blockers

[Tom Christie]

To back that up I'll make a formal commitment to helping review & ensure 
completion of the PR if it *does* get deferred to 1.10.

-- 
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/39828781-b20f-46b7-a49d-7a18554a1b46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.9 release blockers

[Tom Christie]

Given that it addresses such a core component I'd probably rather see it 
deferred to 1.10.

I'd hope that doesn't affect the motivation of the author (it's a fiddly 
bit of work to get right and its good to see it being addressed) but from 
my point of view it'd be better to see it really thoroughly reviewed before 
commit.

As one example it's not clear what the preferred resolution of this point 
 should be. 
Should the `DATA_UPLOAD_MAX_MEMORY_SIZE` guard include accessing 
`request.body` directly or not? (Related to Tim's point re. documentation.)

As I say, its good work, and I'd like to see it reach completion, but its 
not the sort of change we should be rushing.

(I wouldn't oppose a contrary judgement on it tho)

-- 
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/54acf290-b08c-487b-ad2d-962bd26e8cb9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: moving the class-based View base class out of django.views.generic?

[Tom Christie]

Yup, I think that's a good proposal.

-- 
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/61cbcc8c-08d9-42af-83d5-4a8ee3d79dac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why leave explicit null=True when blank is True in IntegerField, DateField etc?

[Tom Christie]

That kind of implicit behavior would just leave things more confused.
Writing a few characters less code isn't a benefit if it comes at the 
expense of making the behavior less obvious.

-- 
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/0e56558e-0efd-467f-8b08-75e20c5e6fae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: request for API review of streaming responses additions

[Tom Christie]

Potential there to treat these as separately reviewable pull requests.

For example - needing streaming template generation doesn't *necessarily* 
imply needing streaming responses. The node-by-node rendering might mean 
imply that less memory is used during the template rendering, even if the 
complete response content all ends up in memory. (I haven't got a handle 
from the pull request on if that'd be the case or not, and it's possible 
that I've misrepresented it, and there's no benefit other than being able 
to stream the output bytes)

More generally: As presented there's lots of technical change, with very 
little simple end-user presentable "why and when this is a benefit?".

* Template.stream()

What's the data to back this up?
Does this result in lower memory usage during the template generation, or 
is there no difference aside from allowing the output to be streamed? If 
there is an internal benefit then how large do those templates need to be 
before that's significant?

* StreamingTemplateResponse

Again, where's the data to back this up? We're introducing a decision point 
for our users without giving them any basis on which to make that decision. 
At what point would I likely want to use this, and what real-world cases 
for our users are driving this? (For really large CSV responses are 
templates a good idea in any case?)

I also don't really understand from the documentation how the behavior for 
SimpleStreamingTemplateResponse and StreamingTemplateResponse differs - 
"does not handle any rendering attributes/methods (including callbacks)" - 
I understand what the callbacks refer to there, but what does the rest of 
that mean?

* django.views.generic.base.StreamingTemplateView

Unclear to me that the decision point this view introduces to users is 
worth the benefit it provides.
Writing a view that streams a simple template is just about as simple a 
view as is possible to write in Django - would it be better if we simply 
took an informed decision on which of TemplateView / StreamingTemplateView 
is likely to be a better default on behalf of our users?

Also lukewarm on introducing a new GCBV that actually just requires a 
one-line addition to an existing GCBV. Should we prefer to instead document 
the usage of `response_class` more fully, rather than extending the API 
surface area?

Apologies for jumping in with the criticisms - intended positively! 
Understand the intent behind this, but a bit wary of changes that come 
across as purely technical with very little in the way of concrete 
demonstration of benefit. Think it'd be good to see it approached from a 
perspective of "what are we actually recommending our users do here?"

Cheers & thanks to everyone for their hard 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8120693f-652f-4767-909b-90a62505f297%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Tom Christie]

Could we give users guidance on overriding the admin's application specific 
static files with global static files if we do this?

Not immediately clear to me what order static files are copied in, but 
presumably it's possible to ensure that the jquery static files included in 
the admin app directory are overridden with user specified ones in a 
project-level static files directory, right?

Also, tho I'm broadly in favor with us staying with up to date with the 
currently active version of jQuery, to clarify: is there anything 
*specific* that we'd be gaining from the switch at this point?

-- 
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/972b31f8-f085-4b42-80fa-ea49abf40721%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

[Tom Christie]

I'm not super convinced that form.instance is widely better than 
form.save(commit=False).
That's even more true if we're not sufficiently convinced by it that we'd 
be deprecating the existing style.

It would:

* Promote making views making in-place changes on the instance -> doesn't 
tend to be a good style.
* Expose the not-quite-an-instance without m2m attributes in what feels 
like a more casual way than the more verbose form.save(commit=False).
* Allow for (mostly) erroneous use of form.instance.save()

Don't feel that strongly about it, and wouldn't be able to make a proper 
judgement call in the absence of a pull request, but it's not terribly 
clear to me what we're gaining here. 

-- 
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/a29ef366-4179-4ca9-865d-baac283a5a5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Report - July 11, 2015

[Tom Christie]

Consistently bloody amazing.
Thanks for doing such a great job.

-- 
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/1f9ff3f3-32cf-4adb-9c9d-9d9f51b295d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Tom Christie]

Amazing work so far. :)

-- 
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/cdfb54ac-0d0b-4367-b904-0b3c32235050%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending the URL Dispatcher (GSoC 2015 proposal)

[Tom Christie]

> E.g., flask uses a simple `` to match an integer and capture it 
in the `id` parameter. Support to check for conflicts would be a lot 
simpler with those patterns. It would definitely be a best-effort feature.

>From my point of view, this by itself would make for a really nicely-scoped 
GSoC project.
Being able to demonstrate an API that allowed the user to switch to a URL 
resolver that used that simpler style would be a really, really nice 
feature,
and also feels like it might actually be a manageable amount of work.
This wouldn't *necessarily* need to allow decorator style routing, instead 
of the current URLConf style, but that might also be a nice addition. 
Personally though I would consider tackling that as an incremental 
improvement.

Things I'd be wary of:

* Anything around "continue resolving" exceptions or object inspection 
during routing, both of which sound like an anti-pattern to me.
* Method based routing. Feel less strongly about this, but still not 
convinced that it's a good style.
* Generic views / model routes / automatic routing. Too broadly defined, 
and with no clear best answer.

Anyways, interesting stuff Marten, look forward to hearing more.

  Tom

-- 
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/bc559676-60d9-48e1-bbe0-7abb52397184%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: JsonResponse and list values

[Tom Christie]

I haven't dug out sources on this, but I think that vulnerability had been 
dealt with a long time ago, and isn't an issue on browsers with any real market 
share today.

Would need to double check though - don't remember where I came across it 
previously.

-- 
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/7b051285-8c64-43b4-b582-b8db6c453f60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Postgres specific fields and third party apps.

[Tom Christie]

Thanks Marc, that's helpful input.

> I would probably have the motivation to create a PR for DRF showing a 
possible travis/testing setup for what I have proposed.

No, don't worry about that. We actually don't have any need to *hit* the 
database in those tests at all, we just need to make sure that the model 
fields get correctly mapped to the equivalent serializer fields. There will 
be mocking-type approaches to those tests that mean less work than 
switching the CI database.


-- 
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/334b3409-ba79-4f6a-bcef-6875c229fd3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Postgres specific fields and third party apps.

[Tom Christie]

I'm not sure if there'll be an actionable outcome of this, but wanted to 
raise it for discussion.

We've started supporting some of the PostgreSQL specific fields in Django 
REST framework, and I ran into a roadblock when adding a new testcase.
Unsurprisingly we're not able to test them without also switching the test 
database to PostgreSQL.

As a third party app that's not something I want to have to do - it'd mean 
a bunch of work, an extra dependency, slower tests, and (unacceptablly) 
more complication for our contributors.

The only way I can see to resolve it would be if we had support for those 
fields with the sqlite backend.
Technically I assume that's feasible - use JSON encoding for storing the 
data (probably easy), and do awfully non-optimal in-memory filtering for 
the field-specific lookups (probably very hard).
There'd also be the obstacle requiring someone with the time and motivation 
to make it happen.

Options I can see:

* The status quo - don't support fields these in SQLite. (I assume this is 
by far the most likely.)
* Support the fields in SQLite, but don't support the lookups. (This'd 
actually hit the sweet spot for me - I can still test against these fields, 
and test cases will run just fine, so long as you're not hitting any field 
specific fitlering in querysets.)
* Support the fields and lookups in SQLite. (Sounds highly unlikely.)

Any thoughts?

Cheers!

   Tom


Aside: I'm not interested in the "you should be testing with the same 
database as you use in production" gumpf here. It's a third party app.

-- 
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/f08447af-395c-4fb0-9f01-d2af3b4b8504%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: resurrecting an old friend, whitespace in forms, #6362

[Tom Christie]

> leaving a ticket open is a better signal for inviting discussion and 
patches.

There's been over 22,000 issues raised in Django's history. It's 
understandable and desirable that maintainers close off tickets 
aggressively if they don't think they should be tackled.

I wouldn't get too hung up on the process there - a sound argument and a 
bit of proactive work is all that's needed to convince folks to take the 
time to reassess something like that issue. Personally I think there's a 
good case to be made for this one so from my point of view, so I'd say go 
ahead, make the proposal, or better still a pull request, make the argument 
and *then* see if it is possible to reach a consensus.

There's clearly absolutely no guarantee it'd be accepted (there's two core 
members in this thread making different judgement calls on it, so it's 
*far* from cut & dried) but you can be sure that folks are willing to put 
the time in to listen to anyone willing to put in a bit of legwork.

Cheers,

  Tom :)

-- 
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/14bdc9b2-3cd5-4ca8-945b-891884da7c5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: resurrecting an old friend, whitespace in forms, #6362

[Tom Christie]

> it will be backwards incompatible for every Django installation out 
there, but also because throwing away data that the user actually entered 
should be an opt-in, not opt-out behavior.

If adequately called out I think there'd be a valid case that the current 
and future issues it'll be causing to applications right now would outweigh 
the risk of compatibility breakages. I can see a couple of cases where I 
might not want stripped whitespace, but only in slightly contrived and edge 
case situations.

Validating and normalizing input at the field level in a way that supports 
the common case by default seems like a good plan to me. I'm not sure I see 
any great difference between a user entering "3.1" in an integer field and 
having 3 returned is so very different from having "hello " return "hello" 
on a char field. And we're not of course throwing anything away at the 
`request.POST` or `Form` layer - it's only once we're validating an 
individual field that the normalization is being applied.

I don't have an great investment in this either way around, but I think 
it's a valid user-focused improvement worth considering *if* someone 
actually puts together a pull request for it.

-- 
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/f62ee326-11a8-447b-a19c-3028b6e7453f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: resurrecting an old friend, whitespace in forms, #6362

[Tom Christie]

Trimming at `request.POST` or at the `Form` layer absolutely isn't 
sensible, and a `normalize` argument is probably just overcomplicating 
things, but I got the impression from that ticket that nobody would have 
any great issue with someone issuing a patch with a `trim_whitespace` flag 
on CharFields and TextFields.

The only thing beside then to resolve would be if we'd be okay with *its 
default being True*, despite the (edge case) backward incompatibility 
that'd cause. That seems to me to be simple and desirable behavior, doesn't 
need any extra settings, and you'd only need to override that argument in 
the bizarre cases where you *don't* want to strip leading and trailing 
whitespace.

Granted that ticket's been around for an *awfully* long time, but it's only 
a case of someone actually acting on it, and seeking a consensus on a 
sensible option, so...

Cheers,

  Tom


On Tuesday, 3 February 2015 17:22:38 UTC, frantisek holop wrote:
>
> good day, 
>
> a recent technical support incident conducted remotely and 
> involving a lot of back and forth of "huh? but i have entered 
> what you sent me" left me my head scratching. 
>
> the reason turned out to be a trailing space in the username of 
> the django admin loginform (thank god for nginx's "$request_body" 
> log_format parameter). 
>
> this of course sent me on an archeological journey into the lands 
> of stackoverflow, blogs, and finally #6362 and this mailing list. 
> it has been some 5 years now since the decision on that 
> controversial ticket. 
>
> i also went through the whole emotianal rollercoaster: 
>
> how come, so many batteries are included, but when it comes to 
> this essential POST best practice, i needed in every single 
> webform i have ever made, and now i have to do it myself? 
> error-prone and not DRY. especially for the admin login form, 
> it is a usability issue. 
>
> vs 
>
> the BDFL is right, silently discarding user input is just wrong. 
> just use a package like happyforms[1], or pick a stackoverflow 
> answer and be done with it. 
>
>
> but wait, then HTML is also wrong, because it silently folds all 
> whitespace into 1 piece of space, we are all used to this.  even 
> if the user entered whitespace is saved, pushing it back onto the 
> web will silently corrupt it (unless taken care of).  i am not 
> saying this requirement does not exist for someone, somewhere, 
> but i have yet to see a site in the wild that needs this (hello, 
> ascii art people).  whitespace in fields was always reserved for 
> government sites :) 
>
>
> it seems to me that there is a vocal group (majority?) that would 
> welcome a simple switch to make whitespace go away _now_, instead 
> of waiting for that perfect solution lurking in the future along 
> the lines of a generic normalize kwarg, or a flag on _every_ 
> {Char,Text}Field on the model or overriding form.fields 
> attributes like required. 
>
> apps that need to preserve the whitespace are the exception, 
> not the rule, and that is why i would prefer not to start every 
> project by overriding BaseForm._clean_fields[2]. 
>
> so i would like to present another idea for a possibe solution, a 
> proposal i have not seen so far: to have a global setting like 
> FORM_STRIP_FIELDS=True or some such and then roughly: 
>
> diff --git a/django/forms/forms.py b/django/forms/forms.py 
> index c9b8cf2..aab737a 100644 
> --- a/django/forms/forms.py 
> +++ b/django/forms/forms.py 
> @@ -8,6 +8,7 @@ from collections import OrderedDict 
>  import copy 
>  import datetime 
>   
> +from django.conf import settings 
>  from django.core.exceptions import ValidationError, NON_FIELD_ERRORS 
>  from django.forms.fields import Field, FileField 
>  from django.forms.utils import flatatt, ErrorDict, ErrorList 
> @@ -355,6 +356,8 @@ class BaseForm(object): 
>  if isinstance(field, FileField): 
>  initial = self.initial.get(name, field.initial) 
>  value = field.clean(value, initial) 
> +elif isinstance(value, basestring) and 
> settings.FORM_STRIP_FIELDS: 
> +value = field.clean(value.strip()) 
>  else: 
>  value = field.clean(value) 
>  self.cleaned_data[name] = value 
>
> i know, it is a big hammer, but for me, it is like the timezone, 
> or csrf, i'd like to just set it, and forget about it. 
>
> -f 
>
> [1] https://pypi.python.org/pypi/happyforms 
> [2] http://chriskief.com/2012/12/21/trim-spaces-in-django-forms/ 
> -- 
> nobody can be exactly like me.  even i have trouble doing so. 
>

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

Re: Settings: lists or tuples?

[Tom Christie]

> So, I've been working on a patch ... Suggestions?

Normalizing on lists as the default throughout is good. Warning about using 
tuples and putting their usage on a deprecation path seems a little 
unnecessary. I don't think that was discussed in this thread, but I've only 
scanned through, so I could be wrong.

If nothing else let's at least treat those as two *separately reviewable* 
pull requests.

-- 
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/c3d819ae-bbcd-4ab1-b5a4-9ae5fab01fc0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Tom Christie]

Hi Andreas,

  I'm completely in agreement with you that *in theory* using tuples would 
be a (very marginal) improvement. I also happen think that the idea that 
tuples are semantically different from simply being  immutable lists is a 
nonsense - regardless of what a particular section of documentation may or 
may not say, language features are defined solely in terms of their 
behavior, they do not have dreams, hopes and grand philosophical outlooks 
on how they should be used.

  However, the simple case that tuples have a far poorer syntax in python 
than lists, and are *very* easy for beginners to get wrong is a good enough 
reason to prefer the usage of lists consistently.

  ("a string")

  ("a tuple",)

Beginners will not be following your "I notate every (globally available) 
constant sequence in the pattern" advice, and no amount of documentation is 
sufficient to prevent it being a very simple and easy error, that might be 
difficult for a beginner to track down. I think that's a bigger and easier 
trap than intentional assignment.

> accidental assignment to the settings object itself could be easily 
prevented with a __setattr__ method on its class

I'd suggest treating that as a separate issue - perhaps if you or someone 
else came up with a pull request that enforced immutability of the settings 
object that'd be considered on it's own merits. (Note that you could 
perfectly well also deal with making translating list and dict objects into 
immutable objects at *that* point of API, even if they're not in the 
settings module.) I haven't given that any great thought, so expect it 
would have it's own set of obstacles to overcome, but I think it's a 
different issue to the topic at hand here, which is really just about 
settling on an acceptable and consistent style.

> maybe a compromise would be to explicitly note in the docs

I'd be against that as unnecessary fluff - doing one thing in the code and 
recommending another in the docs just introduces noise and uncertainty.

The topic's been discussed more that it really deserves, but I understand 
that it can be frustrating if it feels like your reasoned arguments are 
being brickwalled. I wanted to at least contribute and note that I do agree 
with you in theory, even if practically I'd say that lists throughout is 
consistent, clear, and slightly less likely for developers to get wrong.

Cheers,

  Tom


On Tuesday, 20 January 2015 17:52:51 UTC, Andreas Kahnert wrote:
>
> Just for completness: accidential assignment to the settings object itself 
> could be easily prevented with a __setattr__ method on its class, since 
> django yields on various other places about configuration problems it could 
> not be wrong if the programmer gets noted about an illegal assignment. If 
> everything works fine the method will only get called during startup, so 
> there is no runtime overhead. Simplified example:
> def __setattr__(self, key, val):
> if self.configured:
> raise Exception('settings can not be changed after server startup')
> super(LazySettings, self).__setattr__(key, val)
>
> @Carl Meyer: At the first hand you're right, a thing all programmers 
> should know about (if they call themself so), but he assumed there existed 
> some kind of copy-on-read semantic for the settings, because you get 
> something different when imported from django.conf instead directly and 
> because it's a "magical" lazy object.
>
>
> But since you all seem to like lists that much, maybe a compromise would 
> be to explicitly note in the docs that there is a danger in using lists 
> which can be prevented by tuple usage.
>

-- 
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/063919e0-8d5e-4bfc-b6dc-429885fcfbc6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Last call: Meta API (GSoC 2014/PR 3114) is ready for commit

[Tom Christie]

Wonderful - great work Daniel and thanks to everyone else for their hard 
work on review & guidance.
Lovely stuff.

  Tom

On Monday, 5 January 2015 05:12:41 UTC, Russell Keith-Magee wrote:
>
> Hi all,
>
> Following up on my pre-Christmas email - I believe that PR 3114 - the 
> formalisation of _meta - is now ready to land.
>
> https://github.com/django/django/pull/3114
>
> The code has received a detailed review by several members of the core 
> team, including Tim, Carl, Collin, and myself; we've had review notes from 
> many others. The documentation has also been reviewed. The issues raised by 
> those code and documentation reviews have all (to the best of my knowledge) 
> been addressed.
>
> Other than last-minute cleanups (e.g., PEP8 compliance, -Wall checks etc), 
> and the conclusion of one discussion about how to express one particular 
> set of relationships in code, I believe the branch is ready to land.
>
> Unless there are objections, my intention is to land this patch later this 
> week (around Wednesday/Thursday UTC). If anyone has any objections, speak 
> now, etc etc.
>
> Once again, a huge thanks to Daniel for his great work over the summer 
> (and continued work into the winter as we refined the patch for trunk), and 
> to everyone else who has contributed to reviewing his work.
>
> Yours,
> Russ Magee %-)
>
>

-- 
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/51034deb-f021-48bd-a579-ecc37cf64703%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Delivering PR 3114 - The _meta refactor

[Tom Christie]

Thanks Russ, appreciate your time.

I've no great problem with keeping 'through' table API undocumented with 1.8, 
probably doesn't matter too much either way. Just flagging it up, but looks 
like 'no change' there, which is okay.

-- 
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/f52d9809-18dd-4ec8-afcd-1bcef71cc968%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Delivering PR 3114 - The _meta refactor

[Tom Christie]

One thing I'm unclear on: Does the new API contain any (public API) way of 
determining if a relationship has an associated through table?

Entirely possible that I'm being stupid and that's outside the scope of the 
API, but it's the one thing I see in Django REST framework's ModelSerializer 
'_meta' inspection code that's not obviously handled here.

Is it something that needs to be covered? (Of course if we're talking about 1.8 
blockers I've no particular problem if the answer needs to be 'maybe but could 
come later')

Cheers,

  Tom

-- 
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/ab90dc57-fd67-421e-94f4-60829b5af210%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Explicit relative imports

[Tom Christie]

Contrary voice here, but I don't dig explicit relative imports, it's just 
adds an extra decision point for no real benefit.

Personally I always recommend full absolute imports, ordered strictly 
alphabetically - there's then never any room for confusion or decision 
making around how the imports should be written, and it's always tidy and 
consistent.

Not looking to necessarily change the Django project's stance on that, but 
that's the style I use throughout my projects and it's trivial to stick to. 

Cheers,

  Tom

On Wednesday, 12 November 2014 21:59:42 UTC, Jannis Leidel wrote:
>
>
> > On 11 Nov 2014, at 22:51, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
> > 
> > Hello, 
> > 
> > We’ve started using explicit relative imports in newer parts of the 
> Django source tree. They’re short and readable. That’s good. 
> > 
> > I would like to add guidelines about imports in the coding style guide 
> in order to improve consistency. 
> > 
> > My inclination would be to recommend relative imports within 
> “components” but avoid them between “components”, where a component is: 
> > 
> > - a well-defined sub-framework (django.core.cache, django.db, 
> django.forms, django.template, etc.) 
> > - a contrib app 
> > - an app in the tests/ directory 
> > - etc. 
> > 
> > I would discourage going back into parent modules with relative imports 
> because statements such as `from ...spam import eggs` are hard to parse. 
> > 
> > You can see an example of this style in django.apps which has only three 
> files. 
> > 
> > What do you think? 
>
> Yup, the way to go. 
>
> Jannis

-- 
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/7f1a5323-1efd-4891-bc02-eab5d67bc8b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Mptt Admin as an inline form

[Tom Christie]

Hi Neeraj,

This group is for discussion of development of Django itself.
You want the 'Django users' group, 
here... https://groups.google.com/forum/#!forum/django-users

All the best,

  Tom

-- 
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/b61ef35a-8ef8-4aa8-92a3-f390d7a4f27e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Content Negotiation implement

[Tom Christie]

> I'll be trying to enhance my knowledge base about django request response 
and other related stuffs necessary if you please show me some light to get 
started or from where actually should I start.

I'd generally think that a decent place to start would be to write up what 
some of the documentation *before* actually implementing any code.
Figure out where would you describe `request.data` in the Django docs, 
figure out what other bits of the DEP would need to be public documented 
API, ignoring the under-the-hood implementation details what does the user 
need to know about them and how they work?

An alternative way to get involved without necessarily diving right into 
the DEP might be to review any outstanding tickets to do with HTTP handling 
and requests and responses. Even if you don't feel able to resolve any of 
those issues having a browse through and trying to understand them would be 
a good way to start getting to grips with the Django codebase.

Hope that helps,

  Tom

On Sunday, 9 November 2014 13:36:53 UTC, Asif Saifuddin wrote:
>
> Thank you both for your kind response.
>
> I have only almost about a year working with django and still learing. My 
> django and python skills are still so limited as far I know. Reading the 
> dep and other related links of discussions and browsing some source code 
> things are bit overwhelming to me right now :p  but I am willing to expand 
> my technical knowledge  by learning and trying to contribute on this part.
>
> I have some limitations in design decisions and understanding the overall 
> implementation process But still I want to start working on this part 
> primarily with you guys helps and suggestions.
>
> I'll be trying to enhance my knowledge base about django request response 
> and other related stuffs necessary if you please show me some light to get 
> started or from where actually should I start.
>
> Kind Regards
>
> Asif 
>
> On Sun, Nov 9, 2014 at 4:31 PM, Asif Saifuddin  > wrote:
>
>> Thank you both for your kind response.
>>
>> I have only almost about a year working with django and still learing. My 
>> django and python skills are still so limited as far I know. Reading the 
>> dep and other related links of discussions and browsing some source code 
>> things are bit overwhelming to me right now :p  but I am willing to expand 
>> my technical knowledge  by learning and trying to contribute on this part.
>>
>> I have some limitations in design decisions and understanding the overall 
>> implementation process But still I want to start working on this part 
>> primarily with you guys helps and suggestions.
>>
>> I'll be trying to enhance my knowledge base about django request response 
>> and other related stuffs necessary if you please show me some light to get 
>> started or from where actually should I start.
>>
>> Kind Regards
>>
>> Asif 
>>
>>
>> On Saturday, November 8, 2014 3:01:28 PM UTC+6, Asif Saifuddin wrote:
>>>
>>> Hi,
>>>  when https://github.com/django/deps/blob/master/drafts/
>>> content-negotiation.rst this dep is to be implemented in django? 1.8?
>>>
>>> Regards
>>>
>>> Asif
>>>
>>  -- 
>> 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/g1P7H1PhZaY/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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/436d3c71-2567-462d-a035-9880511124ab%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/befd06ef-b4ff-4958-9e7c-c2420b009349%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django Content Negotiation implement

[Tom Christie]

There's no particular timeline for it. The two people most likely to progress 
it are Mark Lavin and myself.

Mark is the author of the DEP and has been busy lately, focusing on releasing 
the "Lightweight Django" book that he's co-authored. He has mentioned that it's 
possible he'll get back to progressing the DEP following on from that.

My priority at the moment is the REST framework kickstarter, perhaps I'd get 
onto the DEP after that, tho as things currently stand I'd prefer if someone 
else was going to be primarily responsible and for me to just help with design 
guidance.

Anyone else is also free to get the ball rolling on it - we've got a very clear 
idea what we need, so it just needs someone to make the commitment to it, in 
which case I'd be very willing to also put some time into guiding it through.

Hope that helps answer your question. Contributions are of course very welcome,

All the best,

  Tom

-- 
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/c8068f76-7ea0-4a3e-aac3-a9ff58036c7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.7, KeyError: u'manager' error

[Tom Christie]

Hi Taenyon,

This list is for development on Django itself.
I see you've also asked the question on the `django-users` mailing list, 
which is the right mailing list for your question.
You'll want to follow up any further questions on the `django-users` thread 
rather than this one.

All the best,

  Tom

On Friday, 17 October 2014 10:18:04 UTC+1, Taenyon Kim wrote:
>
> I had a problem in using django 1.7.
> Example:
>
> class ModelA(models.Model):
> fielda = models.CharField(max_length=10)
>
> class ModelsB(models.Model):
> modela = models.ForeignKey(ModelA)
> fieldb = models.CharField(max_length=10)
>
> when I query like " modela_instance.modelb_set()', I will get KeyError: 
> u'manager'.
>
>
> 
>
> How can I resolve this problem?
>
>
>

-- 
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/c495532e-54da-42fb-baa1-730c20b55e62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should reverse() return a Unicode string?

[Tom Christie]

One point of clarity is that we ought to return the same type for each of 
`reverse`, `request.path`, `request.get_full_path`, `request.path_info`, 
and the values in the `request.GET` dictionary. Given that, the answer is 
clearly "it should be a string".

It's also a little unclear to me what type is currently expected from 
values in the `request.META` dictionary. I believe that the `HTTP_*` keys 
currently return byte objects, but it's not documented, or clear to me if 
that's consistently true.

On Thursday, 18 September 2014 22:11:39 UTC+1, Carl Meyer wrote:
>
> Hi Jon, 
>
> On 09/18/2014 02:01 PM, Jon Dufresne wrote: 
> > In my Django application, I'm making a strong attempt to always deal 
> > with Unicode strings at the application layer. Byte strings are only 
> > handled at the protocol layer -- sending data out on the "wire". If my 
> > application tests if an object is a string, I'll use isinstance(obj, 
> > unicode) (Python2). 
> > 
> > One gotcha that I noticed is that reverse() will always return a byte 
> > string. Tracing this through the code, I see this happens during the 
> > call to iri_to_uri(), as this function creates a string consisting 
> > only of ASCII characters, other characters are escaped. 
> > 
> > Now, reverse() is often used to grab a URL and handle it at the 
> > application layer. It is not reserved only for the protocol layer. An 
> > example would be presenting a URL inside a HTML template, (as an href 
> > or as text), mail, or JSON. 
> > 
> > In my opinion, reverse() should return a Unicode string, even if that 
> > string consists only of ASCII characters. It is not until the string 
> > hits the wire that it ought to be forced to bytes. 
> > 
> > To verify this, I have created a unit test that I placed in 
> > "urlpatterns_reverse.tests.URLPatternReverse" to demonstrate this is 
> > at the Django layer. 
> > 
> > def test_reverse_unicode(self): 
> > name, expected, args, kwargs = test_data[0] 
> > self.assertIsInstance( 
> > reverse(name, args=args, kwargs=kwargs), 
> > six.text_type) 
> > 
> > What do you think? If others agree, I can file a bug and create a pull 
> > request to fix this. 
>
> It makes sense to me that `reverse()` should return a text (unicode) 
> string. A URL may be "just bytes" on the network, but within the Django 
> context it is clearly text. 
>
> I'm a bit concerned about the backwards-compatibility implications, 
> particularly for Python 3 projects where `bytes` and `str` don't 
> silently interoperate. It would be really interesting to hear if anyone 
> on this list has a real-world Python 3 Django project handy and could 
> test the impact of this change. 
>
> Carl 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ec6d2143-2fe5-4f5f-8cbc-9e8236609a3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The greatest proposal yet: rename this damn group

[Tom Christie]

Options?...

* Django core
* Django core development

For comparison the Rails folks have "Ruby on Rails: Talk 
" and "Ruby on 
Rails: Core "

 - Tom

On Friday, 5 September 2014 08:58:19 UTC+1, Robert Grant wrote:
>
> I am one of the happy few who read the line about what this group is for 
> before I started posting. 
>
> However, that line, and the endless supply of people who think this is for 
> Django developers (see also: Java developers are generally considered to be 
> people* who develop in Java, not who develop Java), might be symptoms of 
> the fact that this group has a funny name for something that is both 
> *developed* and *developed in*.
>
> Can we rename it 
> ?
>  
> :) Some semi-serious suggestions (because I can't think of an obvious 
> alternative) :
>
> Django Masters
> Django Private
> Django Debate
> Django Internals
> Aymeric And Friends
>
>
>
>
>
> * Yes, they're still people.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ea6589a1-5b3d-4f20-8de2-bf50dfcaf941%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Requiring GitHub login for actions on Trac

[Tom Christie]

Absolutely +1.

Clearly the most pragmatic choice.

On Thursday, 7 August 2014 13:43:45 UTC+1, Josh Smeaton wrote:
>
> I don't think "vendor lock in" is a good enough reason to avoid it. If 
> GitHub were to go away, the move to a new code platform would be the 
> greater problem. Also, nothing will be "lost". The old usernames will still 
> be there, they just won't be properly linked to your github username. I 
> don't think that's really a major concern either.
>
> > Finally, to be honest, I’d rather adjust Django’s tools to enthusiastic 
> > beginners than grumpy freedom extremists who refuse to use GitHub.
>
> +1
>
> On Thursday, 7 August 2014 16:49:00 UTC+10, Christian Schmitt wrote:
>>
>> I'm a little bit concerned about that.
>> First I'm using a different user on Trac than on Github, so everything I 
>> wrote so far will getting lost (not that bad problem for me), but I think 
>> there are many users who are in the same situation.
>>
>> The next thing is vendor lock-in. What will happen if Github don't have 
>> enough money? Then all usernames would need to migrate back or to another 
>> OAuth provider, then everything could be lost a second time.
>> Or that Github gets bad / mad.
>>
>> Currently we already live in a world were everything gets connected. And 
>> that is really awful. One must consider that Github is definitely a target 
>> for intelligence agencies. And I don't mean the NSA only. 
>> Maybe I'm a little bit too paranoid but at the current state of the 
>> internet we shouldn't try to connect everything, just it is easier to login.
>>
>>
>>
>>
>> 2014-08-07 8:46 GMT+02:00 Aymeric Augustin > >:
>>
>>> To be clear, I have a working implementation of GitHub OAuth that I can
>>> activate as soon as we reach a consensus.
>>>
>>>
>>>
>>> On 7 août 2014, at 02:43, Ben Finney  wrote:
>>>
>>> > −1. I am happy to agree to Django's BTS terms of use, not GitHub's.
>>> > Please don't make the former depend on the latter.
>>>
>>> I didn’t know our Trac installation had terms of use. So, are you
>>> volunteering to jump in and delete spam as it comes in? Or do you
>>> have an alternative proposal?
>>>
>>>
>>>
>>> On 7 août 2014, at 02:47, Shai Berger  wrote:
>>>
>>> > Today, it is possible to contribute to the Django project without a
>>> > Github account. I would like this to remain the case.
>>>
>>> This is possible but in a limited capacity. To be honest, I think that
>>> ship sailed when we moved to GitHub. We would have also moved
>>> issues there if GitHub’s tools were usable.
>>>
>>>
>>>
>>> On 7 août 2014, at 02:58, Andre Terra  wrote:
>>>
>>> > Most importantly, how would Django as a project benefit from this
>>> > choice other than reducing minimal spam?
>>>
>>> Did you just ask “how would Django as a project benefit from having
>>> core devs work on committing patches rather than fighting spam”?
>>>
>>> If you don’t already have a djangoproject.com account, you’re likely to
>>> give up on reporting a small bug just because it’s too complicated to
>>> log in. Considering our target demographic, GitHub OAuth would
>>> eliminate this problem.
>>>
>>> Also, if you’re trying to report a bug anonymously, you’re likely to be
>>> unable to pass the CAPTCHA, and also be unable to report it, because
>>> you’re still getting blocked by the CAPTCHA. See complaints:
>>> https://code.djangoproject.com/search?q=captcha=1=on
>>>
>>> Finally, to be honest, I’d rather adjust Django’s tools to enthusiastic
>>> beginners than grumpy freedom extremists who refuse to use GitHub.
>>>
>>> > A better solution would be to strengthen what it means to have an 
>>> identity
>>> > on djangoproject.com. Rather than restricting user actions to Trac, we
>>> > could motivate users to create something like a Django profile which 
>>> would
>>> > be used for Trac (among may other uses)
>>>
>>> We already have that: https://www.djangoproject.com/~aaugustin/
>>>
>>> > and could later be linked to any OAuth providers, including but not 
>>> limited
>>> > to GitHub.
>>>
>>> We don’t have that.
>>>
>>> > TL;DR Identity on djangoproject.com, Authentication linked to 
>>> multiple OAuth,
>>> > Authorization in Trac.
>>>
>>> Are you volunteering to do this work, and if so, when will it be done?
>>>
>>> > I hope that idea makes sense. I may be just babbling nonsense.
>>>
>>>
>>> I’m sorry, but ideas don’t matter nearly as much as execution here.
>>> We just need working tools — nothing fancy.
>>>
>>>
>>>
>>> On 7 août 2014, at 02:59, Josh Smeaton  wrote:
>>>
>>> > is it easy enough to support github oauth + the current trac auth 
>>> concurrently?
>>> > If a user chooses to go through the harder path, that's fine.
>>>
>>> It may be doable to provide two authentications endpoints, like /login 
>>> and
>>> /login/github. Trac just looks at REMOTE_USER and creates a session that
>>> lasts until you logout. I’ll look 

Re: [GSOC] Weekly update

[Tom Christie]

 1) get_fields should return a list instead of a tuple
>>> Previously, get_fields would return a tuple. The main reason was 
related to memory and immutability. After discussing with Russell, we 
decided this endpoint should actually return a list as it is a more suited 
data structure.
>> Can you clarify the reasons for this choice? If it’s just the purity of 
using the “proper” data type, I’m not sure it beats the practicality of 
returning an immutable iterable and avoiding the cost of a copy or the risk 
of incorrect manipulation.
> This is a design decision, tuple performs better.

I'm confused - does it return a list or a tuple? Your previous answer 
mentioned that it was a list, but you later state "This is a design 
decision, tuple performs better.".

Given that it ought to be immutable, I can't see any reason for it *not* to 
be a tuple.

Great work on all of this!

All the best,

  Tom

On Sunday, 3 August 2014 15:48:04 UTC+1, Daniel Pyrathon wrote:
>
> Hi Aymeric,
>
> Thanks for writing back
>
> On Sunday, August 3, 2014 4:24:27 PM UTC+2, Aymeric Augustin wrote:
>>
>> On 3 août 2014, at 15:11, Daniel Pyrathon  wrote:
>>
>> *1) get_fields should return a list instead of a tuple*
>> Previously, get_fields would return a tuple. The main reason was related 
>> to memory and immutability. After discussing with Russell, we decided this 
>> endpoint should actually return a list as it is a more suited data 
>> structure.
>>
>>
>> Can you clarify the reasons for this choice? If it’s just the purity of 
>> using the “proper” data type, I’m not sure it beats the practicality of 
>> returning an immutable iterable and avoiding the cost of a copy or the risk 
>> of incorrect manipulation.
>>
>
> This is a design decision, tuple performs better. 
>  
>
>>
>> The bugs that would occur if the cached value is altered inadvertently 
>> could be very hard to track down.
>>
>
> Only a couple of days...
>
> https://github.com/PirosB3/django/commit/2411ff58d032c38a3151c1e54198723a86e6a8af
>  
>
>>
>> *2) Move tree cache out of the apps registry*
>> The main optimisation for the new API (described here 
>> https://code.djangoproject.com/wiki/new_meta_api#Mainoptimizationpoints) 
>> is currently storing information on the Apps registry. After discussing 
>> with Russell we agree this shouldn't be the correct place to keep this.
>>
>>
>> +1
>>
>> A solution is to store related fields information separately on each 
>> model (
>> https://github.com/PirosB3/django/pull/5/files#diff-98e98c694c90e830f918eb5279134ab9R275).
>>  
>> This has been done, and all tests pass.
>> Unfortunately, there are performance implications with this approach: we 
>> are storing a new list on each model regardless of if it has related fields 
>> or not. I will be discussing with Russell about performance tomorrow.
>>
>>
>> Is the extra cost incurred only at start up ? How large is it? If it 
>> isn’t too bad and and run time performance is unchanged, it could be 
>> acceptable.
>>
>
> Yes! only at start-up. Once cache warming has finished, everything should 
> be as fast (maybe faster, given that we are accessing properties on the 
> single Options instance).
>  
>
>>
>> *3) Revisiting field types and options*
>> Last week I opened this: 
>> https://groups.google.com/forum/#!topic/django-developers/s2Lp2lTEjAE in 
>> order to discuss with the community possible new field and option names. 
>> This week I have actually revisited the fields and options for get_field/s 
>> and I have come up with the following: (…)
>>
>>
>> The latest iteration looks clear, consistent and straightforward. I like 
>> it.
>>
>
> Thanks! Please feel free to comment with doubts or suggestions.
>  
>
>>
>> -- 
>> Aymeric.
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dad7fb6e-9984-41aa-814e-d373c384b475%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTTP PUT request

[Tom Christie]

Hi Mark,

Sadly Malcolm is no longer with 
us
.

There is a thread 
herefor
 dealing with request parsing which - if it makes it into core - would 
deal with customisable handling of content types on POST, PUT and other 
HTTP methods.  If you're interested in following this up, that thread would 
be the place to discuss things.

All the best,

Tom

On Sunday, 1 December 2013 05:38:00 UTC, Mark Brown wrote:
>
> Hey Malcolm, 
>
> Is this still the case?
> This response was five years ago, why would Django not allow access to PUT 
> and DELETE data? 
>
> On Friday, 10 October 2008 11:09:02 UTC+11, Malcolm Tredinnick wrote:
>>
>>
>> On Thu, 2008-10-09 at 14:13 -0700, DaveV wrote:
>> > Ahh - never mind - I misread the first post.
>> > 
>> > Still, it would seem helpful if PUT data was processed in a way that
>> > was more readily accessible, such as a PUT dictionary like the POST or
>> > GET ones.
>>
>> No, because it would be almost always wrong to do so.
>>
>> The point is that request.POST is designed for web-browser POST
>> submission, which means it's going to be data encoded as a form
>> submission (or a mime-multipart if it contains a file upload). Web
>> browsers are very restricted beasts. Normal web services encompass a
>> much broader range of domains and there's no concept of a "common"
>> format for uploads. You have to look at the content-type and act
>> appropriately. It could be an XML document (or some subtype), image
>> data, a word document... anything. The content is described in the HTTP
>> method. It would be incorrect to attempt to force any of those data
>> types into dictionaries and not particularly useful for Django to
>> special case one particular type that will, in practice, actually be
>> pretty uncommon (machine interacting web services tend to use more
>> structured formats for sending data than form-encoded, since they're
>> sending more complex data than simple forms).
>>
>> If you're doing REST-based web service stuff -- as opposed to just
>> interacting with a web browser -- you should ignore request.POST as well
>> for the same reasons unless you have a very well-understood, restricted
>> domain that happens to always send form-encoded data.
>>
>> Apologies for being unclear in my original post, although you seem to
>> have worked out my intention. I was trying to say that POST and PUT (and
>> OPTIONS and DELETE) are treated identically in that all the data is in
>> raw_post_data, not that there was an attribute for each method. The
>> latter isn't appropriate for general cases.
>>
>> Regards,
>> Malcolm
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/928cbe64-f0de-470e-bace-ff53db326227%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support POST of application/json content type

[Tom Christie]

I've created the ticket 21442 <https://code.djangoproject.com/ticket/21442>to 
track 'Configurable request parsing'.

I've also made a first pass at refactoring the current request parsing into 
a generic interface that can support arbitrary parsers,
and pushed the current status to the ticket_21442 
branch<https://github.com/tomchristie/django/tree/ticket_21442>on my GitHub 
account.

It's likely that the API will need a few design decisions along the way, so 
I'd suggest anyone who's interested in contributing to this work makes sure 
to follow the ongoing work in that branch.

Cheers all,

  Tom

On Thursday, 12 September 2013 11:20:07 UTC+1, Tom Christie wrote:
>
> > why keep data and files separated
>
> Mostly because that's the way it already works, so...
>
> * request.data would essentially provide a strict superset of the 
> functionality that request.POST provides.  In general you'd be able to 
> replace `request.POST` with `request.data` anywhere and seemlessly start 
> supporting JSON or other data without any other changes required.
> * Form expect the data and files to be provided separately which would be 
> awkward otherwise.
>
> > In the absence of strong objection, I will start working on this base. 
>
> Sure thing.  As it happens, I was also considering taking a crack at this 
> in the coming weeks, so please do follow up on this thread linking to your 
> repo if you start working on it, so myself and others can track any 
> progress.  (And perhaps collaborate.)
>
> Cheers :)
>
>   Tom
>
> On Wednesday, 11 September 2013 04:52:08 UTC+1, Stefan Berder wrote:
>>
>> On Tue, Sep 10, 2013 at 12:17 PM, S Berder <sbe...@gmail.com> wrote: 
>> > On Tue, Sep 10, 2013 at 9:05 AM, Curtis Maloney 
>> > <cur...@acommoncreative.com> wrote: 
>> >> 
>> >> On 9 September 2013 19:50, S Berder <sbe...@gmail.com> wrote: 
>> >>> 
>> >>> Gents, 
>> >>> to sum it up, arguments made and details of how I see the 
>> >>> implementation of a response/request encode/decode framework: 
>> >>> 
>> >>> * need a pluggable interface so current content-types are supported 
>> >>> (`application/x-www-form-urlencoded`, `multipart/form-data`), new 
>> >>> types (`application/json`), custom and future types 
>> >>> (`application/vnd.foobar+json` anybody? See 
>> >>> 
>> http://developer.github.com/v3/media/#api-v3-media-type-and-the-future 
>> >>> for example, `application/msgpack`, `application/protobuf`, 
>> >>> `application/capnproto`, etc). 
>> >>> * decoder/encoder map (content-type, decoder) should be smart to 
>> >>> handle patterns like `text/*` or `application/*xml*` and match things 
>> >>> like `Accept: application/json, text/plain, * / *` 
>> >>> * choice of decoder would be made on the Content-Type header, maybe 
>> >>> supporting a raw by default so data is just passed in case of unknown 
>> >>> content type. 
>> >>> * decoder/encoder should be available through `request` and 
>> `response` 
>> >>> objects. 
>> >>> * decoded data structure (python object) would be stored in 
>> `request.data` 
>> >>> * first step is to support requests, next step is to handle responses 
>> >>> with the same pluggable functionality and coherent API. 
>> >>> * A sensible default for response Content-type would be `text/html; 
>> >>> charset=UTF-8`. It should be made available through a setting entry 
>> >>> anyway 
>> >>> 
>> >> 
>> >> You should also have access to the decision made by the data parser as 
>> to 
>> >> which parser was used, instead of having to infer it yourself from the 
>> >> content type header. 
>> > 
>> > Indeed, that's the 4th point of my list, maybe it's not clear as it is 
>> > but this would be supported. 
>> > 
>> >>> 
>> >>> Some questions though: 
>> >>> 
>> >>> * why keep data and files separated, I see no good reason for this 
>> >>> except mimicking PHP's structure. An uploaded file comes from a named 
>> >>> input, I hope to find it in request.data (why do a common structure 
>> >>> otherwise). I might be missing something but nothing indicates a real 
>> >>> need for this in django/http/request.py 
>> >> 
>> >> 
>> >> True, there's some added complexity [small as it is] in form

Re: #18659 -- Deprecating request.REQUEST

[Tom Christie]

> but perhaps we should provide better names for `request.GET` and 
`request.POST` at the same time

Sure, I'd absolutely agree in principle, and for what it's worth REST 
framework provides `.QUERY_PARAMS` and `.DATA` attributes on the request 
which are recommended instead of using `.GET` and `.POST`.  Of course the 
.DATA attribute in that case provides general purpose request parsing, and 
isn't limited to form content types.

The current names are fundamentally incorrect, and I think they help sow 
the seeds for newcomers to misunderstand the basics of HTTP as a result.

Having said that, in practice I don't know if they're something we'd ever 
move away from.

I don't really feel in any position to judge how we weigh up the current 
naming awkwardness versus the pain of introducing such a major API 
difference. 


On Friday, 18 October 2013 14:13:48 UTC+1, James Aylett wrote:
>
> On Wednesday, October 16, 2013 5:48:09 PM UTC+1, Aymeric Augustin wrote:
>  
>
>> While pour point is technically valid as far as request.GET and 
>> request.POST are concerned, in practice they're so commonly used as a 
>> metonymy for HTTP GET and HTTP POST that it's worth having a strong stance 
>> on keeping them separate.
>>
>
> I'm not entirely serious, but perhaps we should provide better names for 
> `request.GET` and `request.POST` at the same time (with compat). One 
> contains some parameters from the request URL (but can be provided on any 
> HTTP verb, not just GET), the other contains data from the request entity, 
> providing it comes in one of two convenient formats that have common usage 
> (and can be provided on various HTTP verbs, not constrained to POST). The 
> current names are misleading if you try to learn HTTP by learning Django 
> (and I'm guessing a lot of people do).
>
> Certainly the ?next / next= case pointed out above by Marc (a pattern I 
> use a fair amount) would read more precisely (in the absence of 
> `request.REQUEST`, which is a clunky, blurry, quite possibly misguiding but 
> technically no worse named convenience).
>
> I'm +1 on deprecating `request.REQUEST`, and maybe +0 on the rest of what 
> I've just said ;-)
>
> J
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a7af947a-8d78-4855-abaa-4625d896e0b6%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

[Tom Christie]

+1 on removing it.
It's usage reinforces incorrect assumptions about the meaning and behaviour 
of `request.POST` and `request.GET`.

> It's hardly ever a good design pattern to handle GET and POST identically

I'd phrase is as "It's hardly ever a good design pattern to handle query 
parameters and request bodies identically", but otherwise exactly this, yes.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3e98864c-ba33-48bf-b693-8006e786dea5%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Working towards a simpler GCBV implementation?

[Tom Christie]

> But django-vanilla-views are not as usable because you cannot 
reuse isolated pieces of functionality like you can with mixins.

The reusable components that it gives you are `GenericView` and 
`GenericModelView`.
Generally they're going to be the baseline that you'd want to work with 
anyways.
As one example of reusing these base components I've refactored Andrew 
Ingram's `django-extra-views` package using vanilla views. (*)
The end result is a set of generic views for dealing with formsets that 
came out something like 2/3 as much code as was previously required, and 
again, with a much simpler more obvious implementation throughout.

> from django.new_views import ..., like was done with new_forms?

Okay, so there's a precedent.
Really I'm still trying to sound out where the community stands on this.
If there was a pull request along these lines should I expect it to get 
rejected out of hand as too much of a radical change, or are folks 
sufficiently convinced that this is a good idea?

Thanks,

  Tom

(*): See https://github.com/tomchristie/django-extra-views - Not properly 
doc'ed or packaged yet, but considering doing so and releasing as a 
`django-vanilla-formsets` package.

On Saturday, 5 October 2013 14:45:38 UTC+1, is_null wrote:
>
> I should state that I have no education and that I have the feeling 
> that I understand GCBVs perfectly. 
>
> But django-vanilla-views are not as usable because you cannot reuse 
> isolated pieces of functionality like you can with mixins. 
>
> Maybe this is a documentation problem ? 
>
> Maybe the docs should explicitly recommend to read the source code ? 
>
> Maybe it should recommend some links for users to sharpen their 
> understanding of GCBVs ? 
>
> Hope this helps 
>
> James 
>
> -- 
> http://yourlabs.org 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/89d68213-f15a-48e0-86bb-f5a77fd364d2%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Permission to use some Django material ?

[Tom Christie]

Hi Stan,

I would simply include some text in the license noting that some images are 
taken from the Django source and their usage is subject to it's license, 
with a link to the Django license.  I'm sure that'd be plenty sufficient 
attribution.

All the best,

  Tom

On Thursday, 3 October 2013 10:13:03 UTC+1, Stan wrote:
>
> Thanks Russ,
>
> Do you know if there is a best way to "suitably attribute" images ? Maybe 
> a text file beside REAME.txt / LICENCE.txt ?
>
> Cheers,
>
> Stanislas
>
> On Thursday, October 3, 2013 11:02:04 AM UTC+2, Russell Keith-Magee wrote:
>>
>> Hi Stanislas,
>>
>> Django is licensed under the terms of the BSD license. This means you can 
>> use any of Django's source code -- including images -- for whatever 
>> purpose, commercial or otherwise, as long as whatever you use is suitably 
>> attributed, and you don't make any claims that what you've done is endorsed 
>> by Django or it's contributors.
>>
>> The license text itself is quite easy to read:
>>
>> https://github.com/django/django/blob/master/LICENSE
>>
>> Yours,
>> Russ Magee %-)
>>
>>
>> On Thu, Oct 3, 2013 at 4:28 PM, Stan  wrote:
>>
>>> Hi,
>>>
>>> I am working on a small app providing Ajax search for a 
>>> ModelChoiceFieldLike in addition to an admin-like related lookup (pop up to 
>>> changelist). Is it possible for me to embed the magnifier image from admin 
>>> statics ? (static/admin/img/selector-search.gif)
>>>
>>> Thanks.
>>>
>>> Stanislas.
>>>
>>> -- 
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/2d566ef5-c4a2-4801-ac42-da77506b7603%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ae579780-fd75-4fa5-8fd0-c884183a7c3e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Working towards a simpler GCBV implementation?

[Tom Christie]

Hi folks,

I recently released an alternative implementation of Django's existing 
class based views.  The intention was to mirror the *exact* same set of 
functionality that we currently provide, but simplify the implementation 
and API.  It's nothing cleverer or grander than a clean re-write, but the 
end result is *significantly* less complex.  The class hierarchy is 
trivial, the API is much smaller, and the flow control is much more obvious.

I won't go into any more here, as there's plenty of detail in the 
documentation:

http://django-vanilla-views.org

There's also useful context in the related blog post, here:

http://dabapps.com/blog/fixing-djangos-generic-class-based-views/

The difficult thing here really is that there's no obvious approach to 
introducing something like this in a backwards compatible way.

It might be that we could take an incremental approach using the standard 
deprecation process, but given the nature of the GCBVs it'd likely be 
pretty awkward.
There might be some bits of deprecation process we simply wouldn't be able 
to deal with in any sensible way, and we'd certainly end up with a 
seriously gnarly implementation during the deprecation period.

I'd be interested in getting some opinions from folks on the following:

* If a simpler GCBV implementation along the lines of django-vanilla-views 
is something we think we should working towards.
* What approaches we might be able to take to dealing with backwards 
compatibility if we did want to do so.

Thanks for your time.

  Tom

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fe19ddbc-a4d4-4dc0-a241-df45f6e73c96%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: A policy on calling super()

[Tom Christie]

I'm not sure that's really sensible style, tho - classes that are intended 
to be used as mixins should call super, and the base class should be the 
last in the hierarchy.

class FooMixin(object):
 def __init__(self):
super(FooMixin, self).__init__()
self.foo = 3

class MyModel(FooMixin, models.Model):
pass

Am I missing some useful case where it's necessary for a mixin class to be 
used as the base class rather than a super class?

On Sunday, 29 September 2013 18:01:38 UTC+1, Alex_Gaynor wrote:
>
> It matters if you're going to mixin a class whose common ancestor is 
> object, e.g.:
>
> class FooMixin(object):
>  def __init__(self):
> self.foo = 3
>
> class MyModel(models.Model, FooMixin):
> pass
>
> if models.Model.__init__ doesn't call super().__init__, then 
> FooMixin.__init__ won't be invoked.
>
> Alex
>
>
> On Sun, Sep 29, 2013 at 10:00 AM, Tom Christie 
> <christ...@gmail.com
> > wrote:
>
>> Calling super in base classes (ie anything that inherits from 'object') 
>> just seems unnecessary and obscure to me.  It's not a pattern I use or have 
>> seen, and after playing around a bit I can't see any sensible case where 
>> it'd make a difference.  `View` should always be the last (right-most) 
>> class in hierarchy, so there shouldn't ever be any parent behaviour that 
>> needs calling into.
>>
>>
>> On Saturday, 28 September 2013 13:34:23 UTC+1, Daniele Procida wrote:
>>>
>>> <https://code.djangoproject.**com/ticket/2<https://code.djangoproject.com/ticket/2>>
>>>  
>>>
>>>
>>> There's some discussion of a particular class, django.views.base.View, 
>>> and whether its __init__() should contain a super(View, self).__init__(). 
>>>
>>> But there's also a wider question of whether there should be a general 
>>> rule about this, whether the integrity of the __init__() chain should be 
>>> maintained, and whether it matters that not all of our classes that are 
>>> likely to be subclassed do it. 
>>>
>>> Any comments? 
>>>
>>> Daniele 
>>>
>>>  -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> -- 
> "I disapprove of what you say, but I will defend to the death your right 
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>  

-- 
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: A policy on calling super()

[Tom Christie]

Calling super in base classes (ie anything that inherits from 'object') 
just seems unnecessary and obscure to me.  It's not a pattern I use or have 
seen, and after playing around a bit I can't see any sensible case where 
it'd make a difference.  `View` should always be the last (right-most) 
class in hierarchy, so there shouldn't ever be any parent behaviour that 
needs calling into.

On Saturday, 28 September 2013 13:34:23 UTC+1, Daniele Procida wrote:
>
>  
>
> There's some discussion of a particular class, django.views.base.View, and 
> whether its __init__() should contain a super(View, self).__init__(). 
>
> But there's also a wider question of whether there should be a general 
> rule about this, whether the integrity of the __init__() chain should be 
> maintained, and whether it matters that not all of our classes that are 
> likely to be subclassed do it. 
>
> Any comments? 
>
> Daniele 
>
>

-- 
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: Support POST of application/json content type

[Tom Christie]

> why keep data and files separated

Mostly because that's the way it already works, so...

* request.data would essentially provide a strict superset of the 
functionality that request.POST provides.  In general you'd be able to 
replace `request.POST` with `request.data` anywhere and seemlessly start 
supporting JSON or other data without any other changes required.
* Form expect the data and files to be provided separately which would be 
awkward otherwise.

> In the absence of strong objection, I will start working on this base. 

Sure thing.  As it happens, I was also considering taking a crack at this 
in the coming weeks, so please do follow up on this thread linking to your 
repo if you start working on it, so myself and others can track any 
progress.  (And perhaps collaborate.)

Cheers :)

  Tom

On Wednesday, 11 September 2013 04:52:08 UTC+1, Stefan Berder wrote:
>
> On Tue, Sep 10, 2013 at 12:17 PM, S Berder  
> wrote: 
> > On Tue, Sep 10, 2013 at 9:05 AM, Curtis Maloney 
> >  wrote: 
> >> 
> >> On 9 September 2013 19:50, S Berder  
> wrote: 
> >>> 
> >>> Gents, 
> >>> to sum it up, arguments made and details of how I see the 
> >>> implementation of a response/request encode/decode framework: 
> >>> 
> >>> * need a pluggable interface so current content-types are supported 
> >>> (`application/x-www-form-urlencoded`, `multipart/form-data`), new 
> >>> types (`application/json`), custom and future types 
> >>> (`application/vnd.foobar+json` anybody? See 
> >>> http://developer.github.com/v3/media/#api-v3-media-type-and-the-future 
> >>> for example, `application/msgpack`, `application/protobuf`, 
> >>> `application/capnproto`, etc). 
> >>> * decoder/encoder map (content-type, decoder) should be smart to 
> >>> handle patterns like `text/*` or `application/*xml*` and match things 
> >>> like `Accept: application/json, text/plain, * / *` 
> >>> * choice of decoder would be made on the Content-Type header, maybe 
> >>> supporting a raw by default so data is just passed in case of unknown 
> >>> content type. 
> >>> * decoder/encoder should be available through `request` and `response` 
> >>> objects. 
> >>> * decoded data structure (python object) would be stored in 
> `request.data` 
> >>> * first step is to support requests, next step is to handle responses 
> >>> with the same pluggable functionality and coherent API. 
> >>> * A sensible default for response Content-type would be `text/html; 
> >>> charset=UTF-8`. It should be made available through a setting entry 
> >>> anyway 
> >>> 
> >> 
> >> You should also have access to the decision made by the data parser as 
> to 
> >> which parser was used, instead of having to infer it yourself from the 
> >> content type header. 
> > 
> > Indeed, that's the 4th point of my list, maybe it's not clear as it is 
> > but this would be supported. 
> > 
> >>> 
> >>> Some questions though: 
> >>> 
> >>> * why keep data and files separated, I see no good reason for this 
> >>> except mimicking PHP's structure. An uploaded file comes from a named 
> >>> input, I hope to find it in request.data (why do a common structure 
> >>> otherwise). I might be missing something but nothing indicates a real 
> >>> need for this in django/http/request.py 
> >> 
> >> 
> >> True, there's some added complexity [small as it is] in forms because 
> File 
> >> fields need to look elsewhere for their values. 
> >> 
> >>> 
> >>> * isn't more or less any data sent to your backend representable as a 
> >>> dict or object with dict access modes? I try to think about 
> >>> occurrences where some data would not have a 'name'. 
> >>> 
> >> 
> >> I frequently send JSON lists of data to my APIs... 
> > Ok, was a bit short sighted on this one, still thinking in terms of 
> > form bound data, it was a long day here in Shanghai. I suppose that 
> > the kind of python object you receive is not so important as you 
> > should do data validation anyway. Your earlier concern about checking 
> > for different content-types doesn't apply to the solution I have in 
> > mind as to whatever data representation you have at the beginning, you 
> > should get a very similar object after decoding. What I mean is if you 
> > send the *same* data through Yaml or JSON, the object in request.data 
> > should be the same or extremely close. I say extremely close because 
> > I'm thinking about xml that is always way more verbose than the others 
> > and *might* add more data to the resulting object. (hint: I don't like 
> > XML, don't need it in what I do and last used it ~8/9 years ago in a 
> > disastrous explosion of SOAP and unix/microsoft interfaces) 
> > 
> > Stefan 
> > -- 
> > http://www.bonz.org/ 
> >  /(bb|[^b]{2})/ 
>
> In the absence of strong objection, I will start working on this base. 
>
> Stefan 
> -- 
> http://www.bonz.org/ 
>  /(bb|[^b]{2})/ 
>

-- 
You received this message because you are subscribed to the Google 

Re: Support POST of application/json content type

[Tom Christie]

 we mimic on the request object. The generally have different use 
>>> cases anyway - one for complex web things and the other for standard web 
>>> browsers.
>>>
>>> (the above is what tom said...)
>>>
>>> Tom - what else do you have in DRF's Request that you would need?
>>>
>>>
>>> On 4 September 2013 12:56, Tom Christie <christ...@gmail.com> wrote:
>>>
>>>> > Creating a request.DATA attribute would break compatibility with old 
>>>> code and seem to me less intuitive.
>>>>
>>>> The implementation would ensure `request.POST` would still be populated 
>>>> for form data.
>>>>
>>>> There wouldn't have to be any backwards incompatible changes, and usage 
>>>> of `request.DATA` (or whatever better name there might be, perhaps simply 
>>>> `request.data`) would be entirely optional for using with generic request 
>>>> parsing, instead of form data only.
>>>>
>>>>
>>>> > Where should request.FILE go in that case
>>>>
>>>> request.FILES would be populated by form data as normal, and would be 
>>>> empty on JSON or other submissions.  In order to support multipart parsing 
>>>> the request parsing API would need to provide for parsers that support 
>>>> file 
>>>> upload, in a similar way that REST framework currently does.
>>>>
>>>> > Would request.POST just be a call to request.DATA?
>>>>
>>>> That's an open question, but I'd probably expect it to only return data 
>>>> if the request contains multipart or url-encoded form data.  (Ie. the 
>>>> behaviour wouldn't change.)
>>>>
>>>> Cheers,
>>>>
>>>>   Tom
>>>>
>>>> On Wednesday, 4 September 2013 12:33:00 UTC+1, Stefan Berder wrote:
>>>>>
>>>>> Tom,
>>>>> I agree that the middleware solution is not the best and in my mind 
>>>>> creates fragmentation of the same type of request handling.
>>>>>
>>>>> A generic content-type framework would make the request parsing more 
>>>>> flexible, stronger to change in the future and open the door to any type.
>>>>>
>>>>> I'm curious about the choice of request.DATA though, when doing a POST 
>>>>> request, I expect the data to be in the POST dictionary and nowhere else. 
>>>>> Creating a request.DATA attribute would break compatibility with old code 
>>>>> and seem to me less intuitive. Where should request.FILE go in that case? 
>>>>> Would request.POST just be a call to request.DATA?
>>>>>
>>>>> Stefan
>>>>>
>>>>> On Wednesday, 4 September 2013 18:13:12 UTC+8, Tom Christie wrote:
>>>>>>
>>>>>> Hi Stefan,
>>>>>>
>>>>>> Sure, I'd be interested in seeing us improve how we deal with JSON 
>>>>>> requests and responses.
>>>>>>
>>>>>> My preference would be to introduce a request parsing and response 
>>>>>> rendering API that allows us to support not just JSON, but any media 
>>>>>> type 
>>>>>> that has a parser installed for it.  (I've commented on some of this 
>>>>>> before, 
>>>>>> here<https://groups.google.com/forum/#!searchin/django-developers/tomchristie%7Csort:date/django-developers/Qr0EorpgYKk/6qyCrVqZwmMJ>,
>>>>>>  
>>>>>> although I think I'm warming towards the idea that it's probably about 
>>>>>> time 
>>>>>> we started addressing at least some of this in core.)
>>>>>>
>>>>>> Unsurprisingly I'd suggest the same general approach that is used in 
>>>>>> REST framework - A lazy `request.DATA` attribute (or similar) that when 
>>>>>> accessed, inspects the media type on the request, and parses the request 
>>>>>> stream with an appropriate parser if possible.  The installed parsers 
>>>>>> can 
>>>>>> be configured globally, or on a per-request basis.  The existing 
>>>>>> multipart 
>>>>>> and form-encoded parsing behaviour would no longer be a special case 
>>>>>> baked 
>>>>>> directly into the request object, but instead be the default installed 
>>>>>> parsers.
>>>>

Re: Support POST of application/json content type

[Tom Christie]

> Creating a request.DATA attribute would break compatibility with old code 
and seem to me less intuitive.

The implementation would ensure `request.POST` would still be populated for 
form data.

There wouldn't have to be any backwards incompatible changes, and usage of 
`request.DATA` (or whatever better name there might be, perhaps simply 
`request.data`) would be entirely optional for using with generic request 
parsing, instead of form data only.

> Where should request.FILE go in that case

request.FILES would be populated by form data as normal, and would be empty 
on JSON or other submissions.  In order to support multipart parsing the 
request parsing API would need to provide for parsers that support file 
upload, in a similar way that REST framework currently does.

> Would request.POST just be a call to request.DATA?

That's an open question, but I'd probably expect it to only return data if 
the request contains multipart or url-encoded form data.  (Ie. the 
behaviour wouldn't change.)

Cheers,

  Tom

On Wednesday, 4 September 2013 12:33:00 UTC+1, Stefan Berder wrote:
>
> Tom,
> I agree that the middleware solution is not the best and in my mind 
> creates fragmentation of the same type of request handling.
>
> A generic content-type framework would make the request parsing more 
> flexible, stronger to change in the future and open the door to any type.
>
> I'm curious about the choice of request.DATA though, when doing a POST 
> request, I expect the data to be in the POST dictionary and nowhere else. 
> Creating a request.DATA attribute would break compatibility with old code 
> and seem to me less intuitive. Where should request.FILE go in that case? 
> Would request.POST just be a call to request.DATA?
>
> Stefan
>
> On Wednesday, 4 September 2013 18:13:12 UTC+8, Tom Christie wrote:
>>
>> Hi Stefan,
>>
>> Sure, I'd be interested in seeing us improve how we deal with JSON 
>> requests and responses.
>>
>> My preference would be to introduce a request parsing and response 
>> rendering API that allows us to support not just JSON, but any media type 
>> that has a parser installed for it.  (I've commented on some of this 
>> before, 
>> here<https://groups.google.com/forum/#!searchin/django-developers/tomchristie%7Csort:date/django-developers/Qr0EorpgYKk/6qyCrVqZwmMJ>,
>>  
>> although I think I'm warming towards the idea that it's probably about time 
>> we started addressing at least some of this in core.)
>>
>> Unsurprisingly I'd suggest the same general approach that is used in REST 
>> framework - A lazy `request.DATA` attribute (or similar) that when 
>> accessed, inspects the media type on the request, and parses the request 
>> stream with an appropriate parser if possible.  The installed parsers can 
>> be configured globally, or on a per-request basis.  The existing multipart 
>> and form-encoded parsing behaviour would no longer be a special case baked 
>> directly into the request object, but instead be the default installed 
>> parsers.
>>
>> Taking this approach makes it trivial to write views that can handle both 
>> JSON and form data, and providing a proper parser API makes it easy for 
>> developers to package up and share their own parser implementation, such as 
>> YAML, XML and MsgPack.  (And, looking forwards, JSON-based media types such 
>> as hypermedia types.)
>>
>> In REST framework this behaviour is (by necessity) implemented in a 
>> Request object that wraps the underlying HttpRequest, but the same basic 
>> implementation can be applied to implementing it directly in the Request 
>> object, and would be somewhat easier.
>>
>> I'm interested to see Marc suggesting middleware specifically for 
>> handling JSON requests.  That'd work, and would be a simple approach.  My 
>> reservations with that would be:
>>
>> * We'd not be making it any easier for users to deal with request parsing 
>> generally.
>> * There's no way to write views that deal with request data in an 
>> agonistic way, and dealing with differing media types would require 
>> switching based on the media type in the view itself.  For example, the 
>> generic views would still only support form data.  As another example, if 
>> you wanted to add, say, MsgPack support to your application, you'd need to 
>> re-write all your views.
>>
>> From my point of view this is already a solved problem, and I'd really 
>> like to see a generic approach to handling request data, and a 
>> corresponding approach to rendering responses into an appropriate media 
>> type.
>>
>>  All the best,
>>
>>   Tom
>>
&g

Re: Support POST of application/json content type

[Tom Christie]

Hi Stefan,

Sure, I'd be interested in seeing us improve how we deal with JSON requests 
and responses.

My preference would be to introduce a request parsing and response 
rendering API that allows us to support not just JSON, but any media type 
that has a parser installed for it.  (I've commented on some of this 
before, 
here,
 
although I think I'm warming towards the idea that it's probably about time 
we started addressing at least some of this in core.)

Unsurprisingly I'd suggest the same general approach that is used in REST 
framework - A lazy `request.DATA` attribute (or similar) that when 
accessed, inspects the media type on the request, and parses the request 
stream with an appropriate parser if possible.  The installed parsers can 
be configured globally, or on a per-request basis.  The existing multipart 
and form-encoded parsing behaviour would no longer be a special case baked 
directly into the request object, but instead be the default installed 
parsers.

Taking this approach makes it trivial to write views that can handle both 
JSON and form data, and providing a proper parser API makes it easy for 
developers to package up and share their own parser implementation, such as 
YAML, XML and MsgPack.  (And, looking forwards, JSON-based media types such 
as hypermedia types.)

In REST framework this behaviour is (by necessity) implemented in a Request 
object that wraps the underlying HttpRequest, but the same basic 
implementation can be applied to implementing it directly in the Request 
object, and would be somewhat easier.

I'm interested to see Marc suggesting middleware specifically for handling 
JSON requests.  That'd work, and would be a simple approach.  My 
reservations with that would be:

* We'd not be making it any easier for users to deal with request parsing 
generally.
* There's no way to write views that deal with request data in an agonistic 
way, and dealing with differing media types would require switching based 
on the media type in the view itself.  For example, the generic views would 
still only support form data.  As another example, if you wanted to add, 
say, MsgPack support to your application, you'd need to re-write all your 
views.

>From my point of view this is already a solved problem, and I'd really like 
to see a generic approach to handling request data, and a corresponding 
approach to rendering responses into an appropriate media type.

 All the best,

  Tom

On Tuesday, 3 September 2013 06:30:04 UTC+1, Stefan Berder wrote:
>
> Hi,
> I looked around the list and couldn't find any mention of this subject.
>
> In `django.http.request.HttpRequest._load_post_and_files()` there is 
> explicit mention of two content type ('multipart/form-data' and 
> 'application/x-www-form-urlencoded'), any other content type will get empty 
> values for self._post.
>
> Given that a lot of user form interaction is now happening through 
> 'XMLHttpRequest', I think that the 'application/json' content type should 
> be supported. A lot of javascript libraries will use json as the default 
> format:
> * angularjs: http://docs.angularjs.org/api/ng.$http, see "Setting HTTP 
> Headers"
> * emberjs: 
> https://github.com/emberjs/data/blob/master/packages/ember-data/lib/adapters/rest_adapter.js#L974
> * backbone: http://backbonejs.org/#Sync
> * jquery: http://api.jquery.com/jQuery.ajax/ (the only one using 
> 'application/x-www-form-urlencoded' by default)
>
> I'm trying primarily to create a discussion on the subject and am ready to 
> provide the code for it as I had to write it. This would help avoid hacks 
> to handle the request object in my view. 
>
> I know there are some apps to handle API construction (django-tastypie, 
> django-rest, django-piston and certainly others) they use either request 
> wrappers or request handling in their views.
>
> Stefan
>

-- 
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: Confusion around generic views queryset cloning.

[Tom Christie]

Thanks both, the responses are very much appreciated.

> It's the same issue as using mutable default arguments or attributes to a 
class. If someone is writing their own generic CBVs without understanding I 
don't see why the queryset case is any more problematic than having a class 
with an empty list defined on it and appending things to it from instances.

True, it's exactly the same issue, although it's more of a gotcha, in that 
appending to a list is explicitly a stateful operation, whereas it's more 
of an implicit side effect when iterating over a queryset.

Something as simple as the following is broken, although it might not be 
obvious on first sight.

class MyView(View):
queryset = Users.objects.all()
template_name = 'foobar'

def get(self, request):
return render(request, self.template_name, {'items': 
self.queryset})

I don't know that there's a huge amount worth doing about that.  We *could* 
add some documentation warning against modifying class attributes on CBV, 
but I'm not sure if it'd just be adding noise and be more confusing that 
it's worth for many users.

> What we could do is add an explanatory comment to the code as to why we 
are doing that and/or change it to use `all()` instead and/or promote 
`clone()` to be a real part of the API.

Generally, ensuring that the GCBVs are implemented using public API seems 
sensible. Anything else is indicative that there's something missing from 
the API that is in fact necessary to end-users. Having said that I really 
don't have strong views on the right approach here.

* `.clone` as public API seems okay, but I'd always prefer to avoid 
introducing new API if it can be avoided.
* Using `.all` also seems okay, but it feels a bit odd that 
`MyModel.objects.all()` would then have end up having a second `.all()` 
operation chained to it during `get_queryset()`.  I realize that's 
equivalent to what's happening now, but it looks odd and might be confusing.
* Continue using `._clone`, but adding a comment in the implementation 
might be sufficient.
* Maybe things are okay as they are right now.

Cheers,

  Tom

On Friday, 12 July 2013 09:43:10 UTC+1, Marc Tamlyn wrote:
>
> I don't think this should need documenting explicitly. It's the same issue 
> as using mutable default arguments or attributes to a class. If someone is 
> writing their own generic CBVs without understanding I don't see why the 
> queryset case is any more problematic than having a class with an empty 
> list defined on it and appending things to it from instances. I think it's 
> quite well documented that the a queryset caches its results.
>
> Also, in many cases in the CBVs this clone is not strictly necessary as 
> the qs is being further filtered (or called with `get` or `count` or some 
> such) in such a way that the original qs is not being used directly.
>
> What we could do is add an explanatory comment to the code as to why we 
> are doing that and/or change it to use `all()` instead and/or promote 
> `clone()` to be a real part of the API.
>
> Hope that makes some sense.
>
>
> On 11 July 2013 22:26, Carl Meyer <ca...@oddbird.net > wrote:
>
>> Hi Tom,
>>
>> (You said in a follow-up this was intended for django-users, but
>> personally I think it's on-topic for -developers, so I'm replying here.)
>>
>> On 07/11/2013 02:54 PM, Tom Christie wrote:
>> > I've noted that the generic view implementations use the private
>> > `_clone` method when returning the queryset attribute
>> > <
>> https://github.com/django/django/blob/master/django/views/generic/detail.py#L72
>> >.
>> >
>> > Presumably the need for that is something to do with the potential for
>> > querysets to be cached or otherwise incorrectly stateful if this cloning
>> > isn't performed.  What's confusing me is that it's not at all obvious
>> > *exactly* what the implications of making (or failing to make) this call
>> > are.
>> >
>> > Furthermore if it *is* something that's strictly required in this
>> > circumstance then do we need to be documenting whatever behavior is
>> > being triggered, so that developers writing their own class based views
>> > don't make the (mistake?) of simply returning/using a queryset attribute
>> > without having first cloned it?
>> >
>> > For example, is the following incorrect?
>> >
>> > class SomeBaseGenericView(View):
>> > queryset = None
>> >
>> > def get_queryset(self):
>> > """
>> > Simply return `.queryset` by default. Subclasses may
>> > override this behavior.
>> > """
>> >  

Confusion around generic views queryset cloning.

[Tom Christie]

I've noted that the generic view implementations use the private `_clone` 
method when returning the queryset 
attribute
.

Presumably the need for that is something to do with the potential for 
querysets to be cached or otherwise incorrectly stateful if this cloning 
isn't performed.  What's confusing me is that it's not at all obvious 
*exactly* what the implications of making (or failing to make) this call 
are.

Furthermore if it *is* something that's strictly required in this 
circumstance then do we need to be documenting whatever behavior is being 
triggered, so that developers writing their own class based views don't 
make the (mistake?) of simply returning/using a queryset attribute without 
having first cloned it?

For example, is the following incorrect?

class SomeBaseGenericView(View):
queryset = None

def get_queryset(self):
"""
Simply return `.queryset` by default. Subclasses may override 
this behavior.
"""
return self.queryset

If so, under what set of conditions can it fail, and is it possible to unit 
test for the failing behavior?

I've dug into the source, but the `_clone` method isn't documented, nor can 
I find anything terribly helpful related to queryset cloning after googling 
around for a while.

Many thanks,

  Tom

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