Re: Support byte range requests in django.views.static.serve

[mdj2]

Apparently, I don't know how to use Google groups. I think I sent something 
directly to Russell, and it wasn't posted here. Oops. Here it is again 
(from memory):

It takes more than just running gunicorn. You'd have to setup Apache or 
Nginx in front. And if Django needs to handle the request first (for 
authentication purposes), then you would have to configure something like 
xsendfile as well.

The Django server was included "so you can develop things rapidly, without 
having to deal with configuring a production server". If you happen to be 
developing with HTML 5 video and audio, the Django server doesn't live up 
to its stated goal.

On Sunday, April 13, 2014 8:43:56 PM UTC-7, Alex_Gaynor wrote:
>
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA256 
>
> I'd be +1 on doing this -- I know we've always said that Django's static 
> serve isn't for production use, but as video and audio are increasingly 
> common on the web, Django should support them seemlessly.
>
> Alex
>
> PS: I'm of course open to other ways of supporting these, such as using 
> Twisted for static file serving. (0.5 wink ;-)
>
> -BEGIN PGP SIGNATURE- 
> Version: Mailvelope v0.8.0 
> Comment: Email security by Mailvelope - http://www.mailvelope.com 
>
> wsFcBAEBCAAQBQJTS1l0CRASX1xn3+lAhAAAzhAP/RJ5RA4zXF8/sog+snpf
> ZhxObrYh04irkjQDcV7Jzs80tsgTWuhZBQgrlPR9ESfsOcIDSTStGGZsDFyR
> y7VnFCa0RFsE/jXi3tkig2VFiK9cNIYbRNyzwETiOVBoiUeP52nq/TUVkAOD
> UUmLbV9wdEXFAc/i/dkgJk4HxIYjzqURMFJ5S+XPi/6jwEF9Ds16ORONPY9o
> nTC9c1auzra91HqxDs/n5OTg8L9p80y3QRrsHx2vrCP7R1yPyteuqeWVd1Lk
> zqvj5/bwHRcMR0Q/oXnjvG3UJuOf+nx3s2o6hFoAHiVfXsrIMOUv/PTnr+Ck
> ayj7+lrRr+wpOr0rfgARFpLv1GggNaug2ZnFfLVGJZ+VGBJ1nWmDq+j8bMEI
> zUEPBUw+BxDWoQXdNUacl9J16YerUw5aaTEzTppwNg65UU6YobvaToSe5Dqe
> nto/8dW/JBXC7YeRCXSxaOoJnX6A7rnI7Typr2pB6PcWPjevSZYxrXuf1Cf3
> YG/5fQ6FRbuh2SevQGO634RiEkr/Z6DbDlEINCBvLPx692aJ31IFOmJSF+ds
> AtDYeJjzDf6oKVdqlMJ0mAft1BIjUzpOGvgMjhQpss4cZBDWHID1T5ZUHdVL
> H7Q+0JAskdC8Oa6BrveGydZZfcQpYyy1sghxwxaXqwKguc8gTwcw2Wsx59un
> waxF 
> =Ofgw 
> -END PGP SIGNATURE- 
>
>
> On Sun, Apr 13, 2014 at 11:30 PM, > wrote:
>
>> Is the Django community interested in supporting HTTP range requests in 
>> django.views.static.serve
>> ?
>>
>> The primary benefit I see is that it makes files served up for  
>> and  "seek-able" with the django server. This generally isn't a 
>> problem for small files (except in 
>> Chrome),
>>  
>> but becomes an issue for larger ones.
>>
>> Werkzeug has a function that parses the range 
>> header,
>>  
>> which I used to support range requests in a Django application. I estimate 
>> that robust support for HTTP range requests would cost <300 lines of code, 
>> plus tests.
>>  
>> -- 
>> 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/37cdec22-e19d-4843-a3e4-a6b1e1bfa86e%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> "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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6839518c-52f6-49f8-838b-6696f215345a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support byte range requests in django.views.static.serve

[Adrian Holovaty]

On Sun, Apr 13, 2014 at 11:30 PM,  wrote:

> Is the Django community interested in supporting HTTP range requests in
> django.views.static.serve
> ?
>

I definitely support this.

I've gotten bitten several times by the development server not supporting
Range headers, and it's the kind of a problem that is quite hard to debug.
I recall it took me about an hour to determine why audio wasn't seeking
properly when it was being served by the development server.

To Russ' point about not using the server in production: we can support
Range without sacrificing our "don't use this in production" goal. Let's
treat our users like consenting adults. We should definitely discourage
people from using the development server in production, but not to the
point where we're neutering the server, making development more difficult.

Long story short: go ahead and implement that robust support, with tests,
and I can take the lead on reviewing the patch. Email me offlist when it's
ready, if you could, so I don't lose track of it. Thanks for bringing this
up!

Adrian

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

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

[Carl Meyer]

Hi Chris,

Just a couple notes to set the record straight:

On Sunday, April 6, 2014 1:02:18 PM UTC-4, Chris Wilson wrote:
>
> Hi Andrew, 
>
> I'm not a Django core contributor but just a user and occasional patcher. 
> I submit some comments on this proposal in the hope that they will be 
> useful. 
>
> On Sun, 6 Apr 2014, Andrew Pashkin wrote: 
>
> > Some Pytest advocacy: 
> > 1) Pytest has convenient tests collection options - you can just specify 
> folder to run all tests in it. It is also possible to 
> > filter tests by regex, and select specific ones. 
>
> I do use pytest and it has a lot of good points. Running all tests in a 
> directory or a specific file is one of them, as is the better test 
> selection logic. 
>
> > class MyTestCase(TestCase): 
> > def test_something(self): 
> >expected_content = ... 
> >response = self.client(...) 
> >self.assertEqual(expected_content, response.content)   
> > 
> > Pytest: 
> > 
> > def test_something(client): 
> > expected_content = ... 
> > response = self.client(...) 
> > assert expected_content == response.content 
>
> But this is not one of them, at least not for me. I strongly dislike this 
> style of assertions: 
>
> > Pytest style is cleaner and complies PEP8. Assertions with assert are 
> more readable. 
>
> * The difference between "self.assertEquals(a, b)" and "assert a == b" is 
> minimal for me. 
>
> * It hides a LOT of magic in how pytest goes back and evaluates the 
> assertion's arguments again if the assertion fails. Sometimes it gets 
> different results (if one of the tested methods has side effects) and then 
> the assertion message makes no sense, hides the problem, or pytest breaks. 
>

This has not been true since pytest 2.1.0, released July 2011. Since then, 
pytest rewrites assertions in the AST via an import hook instead of 
re-evaluating assertion arguments on failure, so there are no such problems 
with side effects in one side of an assertion. See 
http://pytest.org/latest/assert.html for details.
 

> * It makes it much harder to write custom assertions and get meaningful 
> display on error. 
>
> > It is also possible to group tests, by placing them into class without 
> > subclassing something. 
>
> Grouping tests with decorators allows tests to be members of multiple 
> suites, it's true. However this is not something that I've ever needed. 
>
> And losing the power of inheritance to add methods to my test classes, by 
> not putting tests into classes, is enough to kill this style completely 
> for me. I write a LOT of my own assertions: 
>
>https://github.com/aptivate/django-harness/tree/master/django_harness 
>
> > 4) In Pytest it is possible to define setup functions for modules, 
> classes and specific tests. 
>
> I can do this by adding mixins to test classes. Works fine for me, and 
> less magical. 
>
> > 5) Pytest also has fixture mechanism, which allows to use additional 
> > resources in tests by specifying fixture names as an arguments (like 
> > client) - it is good alternative to using setUp's and subclassing 
> > something. 
>
> We have named fixtures in Django test classes already, so I don't see that 
> as much of an advantage. We can't easily add fixtures in mixins at the 
> moment. I've not needed that so far. 
>

Pytest fixtures are a much more general and powerful concept than Django 
fixtures; they allow you to write modular code to setup and teardown any 
type of resource that a test may need.

Django's fixtures are limited to data dumps; IMO data-dump fixtures cause 
test maintainability problems and should usually be avoided (in favor of 
object factories).
 

> > 6) pytest-xdist plugin provides parallel execution of tests. 
> > 7) Pytest has features for writing parametrized tests. 
> > 
> > So Pytest is kind of cool and it is easy to migrate to it. 
>
> I don't think it's necessary or wise to rewrite the test suite to use 
> pytest-style assertions. But better integration of Django and Pytest, and 
> the ability to write tests with Pytest-style assertions if you like, would 
> certainly have my support (fwiw). 
>
> Cheers, Chris. 
> -- 
> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838 
> Citylife House, Sturton Street, Cambridge, CB1 2QF, UK 
>
> Aptivate is a not-for-profit company registered in England and Wales 
> with company number 04980791. 
>

-- 
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/5bb9c004-9251-4fb3-9ae3-5ac8d6513142%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

DEPs: Django Enhancement Proposals

[Adrian Holovaty]

Yesterday at PyCon, about a dozen people from the Django core team had a
lunch meeting to talk about various ideas we should implement. One idea was
to start doing a Django equivalent of Python's PEPs, which would serve as a
formal way to document large new features/changes in Django.

The goal would be to have "design documents" in a single place, rather than
relying on parsing dozens of micro-decisions made in mailing list threads,
Trac tickets, etc. And, importantly, we would only use this for
medium-to-large features, so as not to introduce too much inertia.

We also talked about doing it immediately, just using pull requests on
GitHub, to get some momentum going. No need to build any fancy systems, etc.

Today at the sprints, I went ahead and started drafting how this would
work. Here is a new GitHub repo for DEPs (Django Enhancement Proposals):

https://github.com/django/deps

And here is DEP 1, a draft attempt to document how the process works:

https://github.com/django/deps/blob/master/deps/0001.txt

Note the "TODO: Next steps" at the bottom. I'm not exactly sure what the
best process would be once a DEP is formally created. Can somebody with
more familiarity with Python's PEP process provide some suggestions?

Adrian

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

Re: DEPs: Django Enhancement Proposals

[Donald Stufft]

On Apr 14, 2014, at 1:51 PM, Adrian Holovaty  wrote:

> Yesterday at PyCon, about a dozen people from the Django core team had a 
> lunch meeting to talk about various ideas we should implement. One idea was 
> to start doing a Django equivalent of Python's PEPs, which would serve as a 
> formal way to document large new features/changes in Django.
> 
> The goal would be to have "design documents" in a single place, rather than 
> relying on parsing dozens of micro-decisions made in mailing list threads, 
> Trac tickets, etc. And, importantly, we would only use this for 
> medium-to-large features, so as not to introduce too much inertia.
> 
> We also talked about doing it immediately, just using pull requests on 
> GitHub, to get some momentum going. No need to build any fancy systems, etc.
> 
> Today at the sprints, I went ahead and started drafting how this would work. 
> Here is a new GitHub repo for DEPs (Django Enhancement Proposals):
> 
> https://github.com/django/deps
> 
> And here is DEP 1, a draft attempt to document how the process works:
> 
> https://github.com/django/deps/blob/master/deps/0001.txt
> 
> Note the "TODO: Next steps" at the bottom. I'm not exactly sure what the best 
> process would be once a DEP is formally created. Can somebody with more 
> familiarity with Python's PEP process provide some suggestions?
> 
> Adrian
> 
> -- 
> 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/CABm4ZCT1S1_ybYVe_0BGKvGAsQx3VDsD0KWZtBfR9fD6nOU7vQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

Normally in the PEP process once you have a PEP you go through rounds of 
discussion on the mailing list. The PEP is responsible for documenting the 
solution the PEP suggests as well as any dissenting opinions. Once the PEP 
author believes there is no more discussion to be had they ask for 
pronouncement. This is where the BDFL or BDFL-Delegate (Guido doesn’t care 
about everything, so he can appoint someone to decide in his place) reads over 
the PEP and accepts it or rejects it. If it is accepted the status changes from 
Draft to Accepted and it stays that way until it gets implemented and 
committed. Then it changes from accepted to final and the PEP process is done.

One thing i’m not sure of, how is DEPs going to work without a BDFL? Generally 
they are used to get feedback and provide a clear concise argument to the BDFL 
in cases where there is not a good way to get a rough consensus amongst 
python-dev.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: DEPs: Django Enhancement Proposals

[Alex Gaynor]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

For us, I think the value of a DEP is in putting the conclusion of a
discussion in one place, rather than forcing everyone to read the entire
thread to know how it went. To that end, I don't think anything needs to
change about how we accept DEPs.

Alex

-BEGIN PGP SIGNATURE-
Version: Mailvelope v0.8.0
Comment: Email security by Mailvelope - http://www.mailvelope.com

wsFcBAEBCAAQBQJTTCE4CRASX1xn3+lAhAAAjBoP/3c3P30xlHh1Z3BDvrS5
LHuzyQR/Lp3rws+83Cnh0Xi154xcWkd1np5PvbXXya747NSLEIayryDHiYlw
hhdeGFA77TJxG/q6LRjbDAgFq7YsLERtIYLkWvWmiFTuKZDHELj4oGGs9SQS
LjGm+r0M32LQPpV8yui3rBP1AbBl1/KddztyzzQqNdYEhvahxiScKFaOE+vH
bSbsCONZv1TCFDcpy4y70Mlz9CzLsNpanO9Mjq8066RG0MB9HKr6w5Yqi6OS
ItYQrmiiLcAwARi3BlRqBsmBcWGJ55pOfNXq3GPwScWiQ1ySap2W4+rbml1C
7Fxfp1KIE4DfLmfiQuPgCWZhrpr1hRBdVRXXHvWkYnPmxlXWUFxFwgrtSeZh
fC5t9F3jmSG02L2JnwHjhynSOTyh9d+bCbRE/hdij+DP0v9iZBGNvzQq04Dy
X72xJ99R7mRKHrHjvPa0IMuRqpXia/fPn1+2t2Ujf32nXDc+V3l+BTWm9W+D
b1LFjpfJJwXoho4VK5bPu+NDibWR62HZ64ee3Hq2/g+H7o8WGNPk4YOFwCmS
eLnrM44Zg+nwtzhstiW15nS2znIMrce6Xmllv2lDw1VBawNEdTZ9H5utKu04
Iv3JGLqLP/2g4wQC87ITWvkKwOCNhKROMuizmilqwclW+gsiOQ7cgYj5AOp5
t1gz
=YJkP
-END PGP SIGNATURE-


On Mon, Apr 14, 2014 at 1:54 PM, Donald Stufft  wrote:

>
> On Apr 14, 2014, at 1:51 PM, Adrian Holovaty  wrote:
>
> Yesterday at PyCon, about a dozen people from the Django core team had a
> lunch meeting to talk about various ideas we should implement. One idea was
> to start doing a Django equivalent of Python's PEPs, which would serve as a
> formal way to document large new features/changes in Django.
>
> The goal would be to have "design documents" in a single place, rather
> than relying on parsing dozens of micro-decisions made in mailing list
> threads, Trac tickets, etc. And, importantly, we would only use this for
> medium-to-large features, so as not to introduce too much inertia.
>
> We also talked about doing it immediately, just using pull requests on
> GitHub, to get some momentum going. No need to build any fancy systems, etc.
>
> Today at the sprints, I went ahead and started drafting how this would
> work. Here is a new GitHub repo for DEPs (Django Enhancement Proposals):
>
> https://github.com/django/deps
>
> And here is DEP 1, a draft attempt to document how the process works:
>
> https://github.com/django/deps/blob/master/deps/0001.txt
>
> Note the "TODO: Next steps" at the bottom. I'm not exactly sure what the
> best process would be once a DEP is formally created. Can somebody with
> more familiarity with Python's PEP process provide some suggestions?
>
> Adrian
>
> --
> 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/CABm4ZCT1S1_ybYVe_0BGKvGAsQx3VDsD0KWZtBfR9fD6nOU7vQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> Normally in the PEP process once you have a PEP you go through rounds of
> discussion on the mailing list. The PEP is responsible for documenting the
> solution the PEP suggests as well as any dissenting opinions. Once the PEP
> author believes there is no more discussion to be had they ask for
> pronouncement. This is where the BDFL or BDFL-Delegate (Guido doesn’t care
> about everything, so he can appoint someone to decide in his place) reads
> over the PEP and accepts it or rejects it. If it is accepted the status
> changes from Draft to Accepted and it stays that way until it gets
> implemented and committed. Then it changes from accepted to final and the
> PEP process is done.
>
> One thing i’m not sure of, how is DEPs going to work without a BDFL?
> Generally they are used to get feedback and provide a clear concise
> argument to the BDFL in cases where there is not a good way to get a rough
> consensus amongst python-dev.
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>
>


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

Re: DEPs: Django Enhancement Proposals

[Aymeric Augustin]

On 14 avr. 2014, at 19:51, Adrian Holovaty  wrote:

> One idea was to start doing a Django equivalent of Python's PEPs, which would 
> serve as a formal way to document large new features/changes in Django.

Would it be interesting to retro-spec the major features added in the past?

-- 
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/58B4EA9B-C450-476D-A9E9-8008718FF912%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: DEPs: Django Enhancement Proposals

[Michael Manfre]

I think there would be value in adding DEPs for the major features that
will ship with 1.7.

Regards,
Michael Manfre




On Mon, Apr 14, 2014 at 2:17 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 14 avr. 2014, at 19:51, Adrian Holovaty  wrote:
>
> > One idea was to start doing a Django equivalent of Python's PEPs, which
> would serve as a formal way to document large new features/changes in
> Django.
>
> Would it be interesting to retro-spec the major features added in the past?
>
> --
> 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/58B4EA9B-C450-476D-A9E9-8008718FF912%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: DEPs: Django Enhancement Proposals

[Andrew Farrell]

Who is responsible then for deciding what the conclusion of the discussion
was? If there is no such person, how does the process handle the case when
people talk past each other and don't actually come to a conclusion?


On Mon, Apr 14, 2014 at 2:22 PM, Michael Manfre  wrote:

> I think there would be value in adding DEPs for the major features that
> will ship with 1.7.
>
> Regards,
> Michael Manfre
>
>
>
>
> On Mon, Apr 14, 2014 at 2:17 PM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> On 14 avr. 2014, at 19:51, Adrian Holovaty  wrote:
>>
>> > One idea was to start doing a Django equivalent of Python's PEPs, which
>> would serve as a formal way to document large new features/changes in
>> Django.
>>
>> Would it be interesting to retro-spec the major features added in the
>> past?
>>
>> --
>> 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/58B4EA9B-C450-476D-A9E9-8008718FF912%40polytechnique.org
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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/CAGdCwBv7qvwv8Ksdajz1UUWgYcXEt%3DPLHfZCRjGW0YjT_TW51Q%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CA%2By5TLa1o9PO4yNAt_7EELaU4H9MoXH-3DuVObKKW%3DjYopizyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEPs: Django Enhancement Proposals

[Alex Gaynor]

The same way we do now?


On Mon, Apr 14, 2014 at 3:34 PM, Andrew Farrell wrote:

> Who is responsible then for deciding what the conclusion of the discussion
> was? If there is no such person, how does the process handle the case when
> people talk past each other and don't actually come to a conclusion?
>
>
> On Mon, Apr 14, 2014 at 2:22 PM, Michael Manfre  wrote:
>
>> I think there would be value in adding DEPs for the major features that
>> will ship with 1.7.
>>
>> Regards,
>> Michael Manfre
>>
>>
>>
>>
>> On Mon, Apr 14, 2014 at 2:17 PM, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>>
>>> On 14 avr. 2014, at 19:51, Adrian Holovaty  wrote:
>>>
>>> > One idea was to start doing a Django equivalent of Python's PEPs,
>>> which would serve as a formal way to document large new features/changes in
>>> Django.
>>>
>>> Would it be interesting to retro-spec the major features added in the
>>> past?
>>>
>>> --
>>> 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/58B4EA9B-C450-476D-A9E9-8008718FF912%40polytechnique.org
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> 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/CAGdCwBv7qvwv8Ksdajz1UUWgYcXEt%3DPLHfZCRjGW0YjT_TW51Q%40mail.gmail.com
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/CA%2By5TLa1o9PO4yNAt_7EELaU4H9MoXH-3DuVObKKW%3DjYopizyA%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
"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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFRnB2VVbvarWOWa4BGKqNFn_EFz%2BntyTqpg6iLxdBbMrOexEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEPs: Django Enhancement Proposals

[Albert O'Connor]

+1


On Mon, Apr 14, 2014 at 3:39 PM, Alex Gaynor  wrote:

> The same way we do now?
>
>
> On Mon, Apr 14, 2014 at 3:34 PM, Andrew Farrell wrote:
>
>> Who is responsible then for deciding what the conclusion of the
>> discussion was? If there is no such person, how does the process handle the
>> case when people talk past each other and don't actually come to a
>> conclusion?
>>
>>
>> On Mon, Apr 14, 2014 at 2:22 PM, Michael Manfre wrote:
>>
>>> I think there would be value in adding DEPs for the major features that
>>> will ship with 1.7.
>>>
>>> Regards,
>>> Michael Manfre
>>>
>>>
>>>
>>>
>>> On Mon, Apr 14, 2014 at 2:17 PM, Aymeric Augustin <
>>> aymeric.augus...@polytechnique.org> wrote:
>>>
 On 14 avr. 2014, at 19:51, Adrian Holovaty  wrote:

 > One idea was to start doing a Django equivalent of Python's PEPs,
 which would serve as a formal way to document large new features/changes in
 Django.

 Would it be interesting to retro-spec the major features added in the
 past?

 --
 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/58B4EA9B-C450-476D-A9E9-8008718FF912%40polytechnique.org
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>  --
>>> 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/CAGdCwBv7qvwv8Ksdajz1UUWgYcXEt%3DPLHfZCRjGW0YjT_TW51Q%40mail.gmail.com
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" 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/CA%2By5TLa1o9PO4yNAt_7EELaU4H9MoXH-3DuVObKKW%3DjYopizyA%40mail.gmail.com
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> "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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFRnB2VVbvarWOWa4BGKqNFn_EFz%2BntyTqpg6iLxdBbMrOexEA%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Albert O'Connor
@amjoconn 

avocadoproject.ca / albertoconnor.ca

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

Re: Support byte range requests in django.views.static.serve

[Russell Keith-Magee]

On Tue, Apr 15, 2014 at 1:42 AM, Adrian Holovaty  wrote:
> On Sun, Apr 13, 2014 at 11:30 PM,  wrote:
>>
>> Is the Django community interested in supporting HTTP range requests in
>> django.views.static.serve?
>
>
> I definitely support this.
>
> I've gotten bitten several times by the development server not supporting
> Range headers, and it's the kind of a problem that is quite hard to debug. I
> recall it took me about an hour to determine why audio wasn't seeking
> properly when it was being served by the development server.
>
> To Russ' point about not using the server in production: we can support
> Range without sacrificing our "don't use this in production" goal. Let's
> treat our users like consenting adults. We should definitely discourage
> people from using the development server in production, but not to the point
> where we're neutering the server, making development more difficult.

I accept the use case, but I'm still not wild about the solution. I
can certainly accept that making it easier to develop media-rich apps
would be a good thing. However, rather than add a bunch of features to
a view in Django and then try to describe when you shouldn't use it,
I'd prefer to use that effort to replace the devserver with something
equally easy to use, but based off a base that is an actual real live
web server. That way, we'd end up with a "devserver", but it would be
an actual server, not a hack with a bunch of "please don't actually
use this" warnings, we don't end up spending a bunch of time
developing a feature that is already implemented better elsewhere, and
it would be one step closer to having production mirror development.

This is a lot more plausible now that we have good packaging tools.
There have also been a bunch of vague discussions over the last couple
of years on this topic.

That said, I'm also not especially motivated to work on this
personally - I'm just expressing my architectural concerns. Count me
as a -0, not a -1.

Yours,
Russ Magee %-)

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

Re: DEPs: Django Enhancement Proposals

[Russell Keith-Magee]

On Tue, Apr 15, 2014 at 2:17 AM, Aymeric Augustin
 wrote:
> On 14 avr. 2014, at 19:51, Adrian Holovaty  wrote:
>
>> One idea was to start doing a Django equivalent of Python's PEPs, which 
>> would serve as a formal way to document large new features/changes in Django.
>
> Would it be interesting to retro-spec the major features added in the past?

I agree - there are a bunch of wiki pages that capture a lot of this
information; it wouldn't be a whole lot of effort to turn this into
formal DEP documents.

https://code.djangoproject.com/wiki/ClassBasedViews
https://code.djangoproject.com/wiki/ContribAuthImprovements
https://code.djangoproject.com/wiki/ContribEmailAuth (not yet finalised)
https://code.djangoproject.com/wiki/AppLoadingRefactor (partial;
doesn't include everything Aymeric did, but there are other mailing
list threads)
https://code.djangoproject.com/wiki/FileStorageRefactor
https://code.djangoproject.com/wiki/LoggingProposal (includes link to
mailing list with the full details)
https://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl (proposed,
but never actioned)
https://code.djangoproject.com/wiki/SchemaEvolution (older; probably
not relevant)

Russ %-)

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

Re: DEPs: Django Enhancement Proposals

[Mark Lavin]

I'll be the first one to bite and submit 
one https://github.com/django/deps/pull/1 It needs a lot of work as noted 
in the PR but I'm happy to be a guinea pig for the process.

Best,

Mark

On Monday, April 14, 2014 8:41:07 PM UTC-4, Russell Keith-Magee wrote:
>
> On Tue, Apr 15, 2014 at 2:17 AM, Aymeric Augustin 
> > wrote: 
> > On 14 avr. 2014, at 19:51, Adrian Holovaty 
> > > 
> wrote: 
> > 
> >> One idea was to start doing a Django equivalent of Python's PEPs, which 
> would serve as a formal way to document large new features/changes in 
> Django. 
> > 
> > Would it be interesting to retro-spec the major features added in the 
> past? 
>
> I agree - there are a bunch of wiki pages that capture a lot of this 
> information; it wouldn't be a whole lot of effort to turn this into 
> formal DEP documents. 
>
> https://code.djangoproject.com/wiki/ClassBasedViews 
> https://code.djangoproject.com/wiki/ContribAuthImprovements 
> https://code.djangoproject.com/wiki/ContribEmailAuth (not yet finalised) 
> https://code.djangoproject.com/wiki/AppLoadingRefactor (partial; 
> doesn't include everything Aymeric did, but there are other mailing 
> list threads) 
> https://code.djangoproject.com/wiki/FileStorageRefactor 
> https://code.djangoproject.com/wiki/LoggingProposal (includes link to 
> mailing list with the full details) 
> https://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl (proposed, 
> but never actioned) 
> https://code.djangoproject.com/wiki/SchemaEvolution (older; probably 
> not relevant) 
>
> Russ %-) 
>

-- 
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/a6c0d818-3683-4bfd-8834-9379ff92c388%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Loic Bistuer]

I'm +1 on this.

I do "forms in the templates" with a `{% field %}` templatetag that 
controls labels, placeholders, help_texts, etc.; The lack of multilines 
statements makes it rather painful.

It's interesting to note that Jinja2 supports this and we may be switching 
to it as the default template engine. 
(https://groups.google.com/d/topic/django-developers/Bk-22bKqCTo/discussion).

In that respect, is it still worth investing time on DTL? It's an 
interesting question generally, but it applies here particularly because 
such a switch would fix this very issue.

Votes expressed by core developers so far: 2x -1, 1x -0, 4x +1. Would the 
two -1 consider switching to -0 if the proposed patch turns out to be 
usable?

-- 
Loic

-- 
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/420eb9bd-f9fd-47df-af26-425697577bd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEPs: Django Enhancement Proposals

[Jannis Leidel]

On 14.04.14 13:51, Adrian Holovaty wrote:

Yesterday at PyCon, about a dozen people from the Django core team had a
lunch meeting to talk about various ideas we should implement. One idea
was to start doing a Django equivalent of Python's PEPs, which would
serve as a formal way to document large new features/changes in Django.

The goal would be to have "design documents" in a single place, rather
than relying on parsing dozens of micro-decisions made in mailing list
threads, Trac tickets, etc. And, importantly, we would only use this for
medium-to-large features, so as not to introduce too much inertia.

We also talked about doing it immediately, just using pull requests on
GitHub, to get some momentum going. No need to build any fancy systems, etc.

Today at the sprints, I went ahead and started drafting how this would
work. Here is a new GitHub repo for DEPs (Django Enhancement Proposals):

https://github.com/django/deps

And here is DEP 1, a draft attempt to document how the process works:

https://github.com/django/deps/blob/master/deps/0001.txt

Note the "TODO: Next steps" at the bottom. I'm not exactly sure what the
best process would be once a DEP is formally created. Can somebody with
more familiarity with Python's PEP process provide some suggestions?


I've just fixed a few formatting issues with the files, including 
renaming it to 0001.rst to use Github's automatic rST rendering.


The new URL is:

  https://github.com/django/deps/blob/master/deps/0001.rst

What I also wanted to point out is that the copyright statement at the 
end of DEP 1 ("This document has been placed in the public domain.") 
doesn't have any meaning in many legal jurisdiction, e.g. Germany. We 
should instead promote using the Creative Commons Zero (CC0) license 
which is "giving creators a way to waive all their copyright and related 
rights in their works to the fullest extent allowed by law".


It's what I have been told comes closest to a "public domain" license 
that works for global projects like Django. It was specifically created 
to handle situations like we have with the DEPs now.


More info: http://creativecommons.org/about/cc0 (including FAQ)

Jannis

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

Re: DEPs: Django Enhancement Proposals

[Aymeric Augustin]

On 15 avr. 2014, at 02:41, Russell Keith-Magee  wrote:

> On Tue, Apr 15, 2014 at 2:17 AM, Aymeric Augustin
>  wrote:
>> \Would it be interesting to retro-spec the major features added in the past?
> 
> I agree - there are a bunch of wiki pages that capture a lot of this
> information; it wouldn't be a whole lot of effort to turn this into
> formal DEP documents.

I've also sent a few proposals to this mailing list that could easily be turned
into DEPs.

In order to keep some sense of chronology, I propose to reserve numbers
1XY for features implemented in Django 1.X and to start at 200 for new DEPs.

-- 
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/6474BAFF-9D5A-4F7A-8819-6301677D8DD2%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: DEPs: Django Enhancement Proposals

[Russell Keith-Magee]

On Tue, Apr 15, 2014 at 2:32 PM, Aymeric Augustin
 wrote:
> On 15 avr. 2014, at 02:41, Russell Keith-Magee  
> wrote:
>
>> On Tue, Apr 15, 2014 at 2:17 AM, Aymeric Augustin
>>  wrote:
>>> \Would it be interesting to retro-spec the major features added in the past?
>>
>> I agree - there are a bunch of wiki pages that capture a lot of this
>> information; it wouldn't be a whole lot of effort to turn this into
>> formal DEP documents.
>
> I've also sent a few proposals to this mailing list that could easily be 
> turned
> into DEPs.
>
> In order to keep some sense of chronology, I propose to reserve numbers
> 1XY for features implemented in Django 1.X and to start at 200 for new DEPs.

… and we should probably reserve DEP8 for our coding style guide :-)

Russ %-)

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

Re: DEPs: Django Enhancement Proposals

[Aymeric Augustin]

On 15 avr. 2014, at 08:41, Russell Keith-Magee  wrote:

> ... and we should probably reserve DEP8 for our coding style guide :-)

... which brings the question of the relation between DEPs and online docs.

We already have a coding style guide in the docs.

I assume it's fine if DEP8 is just a link to that page.

-- 
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/6D486B04-E3FD-4E17-A128-0485E543BD6F%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.