Re: Revisiting multiline tags

[Loic Bistuer]

On Thursday, April 17, 2014 5:47:10 AM UTC+7, Josh Smeaton wrote:
>
> And for the last month or so a patch has existed and feedback has been 
> requested. Performance was one of the concerns mentioned, so download 
> Curtis' patch, and test that it works for your use case. He has asked for 
> feedback a number of times. Unless you try it out, I fear that you won't be 
> seeing multi-line tags.
>

My thought exactly.

I intend to review the patch, benchmark it, and work on improvements if 
need be, but that's no replacement for extensive community testing. This 
patch doesn't stand a chance unless the latter has happened since we can't 
risk breaking all the templates out there; the diff may look small, but 
it's a significant change to the parsing algorithm.

Decision making in Django goes by "rough consensus and working code". The 
DEP process that Curtis started is the right way to work constructively on 
"rough consensus", but people who really want this feature need to play 
their part in coming up with "working code" and the code needs to be well 
tested to be considered as working.

If you want this feature, please try the patch against your own projects 
and report your findings. The DEP is also awaiting community feedback.

-- 
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/91238cf7-8073-47ea-aef3-86f973a88284%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Write unit tests for JavaScript

[Russell Keith-Magee]

On Thu, Apr 17, 2014 at 5:57 AM, Trey Hunner  wrote:

> I saw a previous discussion about JavaScript testing in Django but it
> looks like there hasn't been any progress in a few years.
>
> Some of my thoughts on this issue:
>
> This would require choosing a JavaScript testing framework.  There are
> many good ones out there.  A popular one should probably used for easier
> community support.
>
> Unit testing JavaScript (ideally) should not require running the Django
> server.
>
> JavaScript tests will probably require introducing Node.js into the
> automated testing process.  Tests can be run manually from the browser, but
> automated JavaScript tests tend to require Node.js and sometimes PhantomJS
> (for headless testing).
>
> The JavaScript tests should be run as part of the CI testing process.  If
> the tests are run standalone this should be easy to do using a single
> command (possibly requiring grunt or a similar task runner).
>
> This seems like it would be a big change, but I think it could be done in
> small steps.  Setting up the testing framework is the first big step.
>
> What do others think about this issue?
>

I have two thoughts:

1) More testing doubleplus good. :-)

2) Is there anything that can save us from the Node.js kudzu? :-)

As with your previous question about linting, I don't have any firm
opinions about this, beyond "Yes, we should do it".

My suggestion here would be to proceed as if we all agree that this is a
good idea (more testing good, etc), and make a concrete proposal. It's a
lot easier to discuss a concrete proposal than to just kick around
buzzwords and hope some of them stick :-).

You've definitely identified that this is a long term project; so if you
can lay out a map for the way forward, with an indication of the end goal,
that would be a fantastic start IMHO.

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

Re: Proposal: document and enforce style of all files (including JS, CSS, HTML)

[Russell Keith-Magee]

Hi Trey,

Sounds like a reasonable proposal to me. Our JavaScript code has… evolved,
shall we say… over the years. We've recently started enforcing Flake8
compliance on our Python codebase; adopting similar rigour for our
JavaScript code would seem appropriate.

The only open question I can see is the choice of linter -- I don't have
any firm opinions; I'd be interested if others agree with jshint as a good
choice.

Yours,
Russ Magee %-)



On Thu, Apr 17, 2014 at 5:37 AM, Trey Hunner  wrote:

> The JavaScript files use 4 spaces, 2 spaces, or tabs (depending on the
> file).  The CSS files use mostly 4 spaces, and the HTML files use mostly 2
> spaces and sometimes 4 spaces.
>
> The JavaScript code is unlinted and the general code style is neither
> documented nor enforced.  I think jshint should be used for JavaScript
> linting and to help clean up the JavaScript code.  It should also be built
> into the test process (via running "jshint .").  Optionally, it could also
> be run automatically through tox or a fabric/invoke/grunt configuration.
>
> I opened a ticket and pull request related to this issue:
> https://code.djangoproject.com/ticket/22463#comment:2
>
> Based on the errors I've seen in the JavaScript code so far, I think a
> code review may be sufficient for ensuring that the changed files continue
> to work as expected.
>
> --
> Trey Hunner
>
> --
> 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/CACuWcAwrCq_q4%2BFkKOVU5nqokSSgM7wqzXPbo%2BKJh0U%3DY1ecVA%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/CAJxq849rG_D6vVkbCW2ntbSosw-yB_c2L%3DJPdQQD8HjgJ9Y0CQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Josh Smeaton]

And for the last month or so a patch has existed and feedback has been 
requested. Performance was one of the concerns mentioned, so download 
Curtis' patch, and test that it works for your use case. He has asked for 
feedback a number of times. Unless you try it out, I fear that you won't be 
seeing multi-line tags.

I think it's fairly obvious that this idea has gained traction - so go and 
test the implementation: 
https://github.com/funkybob/django/compare/multiline-templates

On Thursday, 17 April 2014 07:43:45 UTC+10, Andre Terra wrote:
>
> On Wed, Apr 16, 2014 at 12:46 PM, imfletcher  > wrote:
>
>> to say this shouldn't be supported because its not aesthetically pleasing 
>> is beyond bizarre, IMO.  If you don't like it, keep it on one line.  If you 
>> are so offended by it that you cannot stand seeing it, ask your team not to 
>> do it.  heck, write a script to remove the whitespace upon checkin.  To 
>> demand the entire world comply.. well, at least remove the B from the title.
>
>
>
> I *absolutely* agree. This is too long a discussion on a matter of 
> personal style, when many other things are much pressing. This isn't even 
> worth being put into a DEP, in my opinion. It is precisely the sort of 
> small feature that isn't worth discussing so thoroughly. 70+ e-mails over 
> this subject is a bit too much, if you ask me. I haven't taken the time to 
> count the votes, but I would hazard a guess that the score is about +75 vs 
> -3 at the moment.
>
> The complexity of long tags is going to be present, whether or not we 
> allow developers to break them into multiple lines. Therefore, the argument 
> against multiline tags on the currently proposed DEP is absolutely moot. 
> Even if we account for the fact that developers might find it easier to 
> write slopping code after we allow for multiline tags, the same could be 
> said of any other part of Django, so that argument doesn't hold water 
> either.
>
> Just my 2 cents..
>
>
> Cheers,
> AT
>
>
>

-- 
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/67d5028e-80d7-4fdd-ba99-7b626b163b75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal: Write unit tests for JavaScript

[Trey Hunner]

I saw a previous discussion about JavaScript testing in Django but it looks
like there hasn't been any progress in a few years.

Some of my thoughts on this issue:

This would require choosing a JavaScript testing framework.  There are many
good ones out there.  A popular one should probably used for easier
community support.

Unit testing JavaScript (ideally) should not require running the Django
server.

JavaScript tests will probably require introducing Node.js into the
automated testing process.  Tests can be run manually from the browser, but
automated JavaScript tests tend to require Node.js and sometimes PhantomJS
(for headless testing).

The JavaScript tests should be run as part of the CI testing process.  If
the tests are run standalone this should be easy to do using a single
command (possibly requiring grunt or a similar task runner).

This seems like it would be a big change, but I think it could be done in
small steps.  Setting up the testing framework is the first big step.

What do others think about this issue?

-- 
Trey Hunner

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

Re: Revisiting multiline tags

[Andre Terra]

On Wed, Apr 16, 2014 at 12:46 PM, imfletcher  wrote:

> to say this shouldn't be supported because its not aesthetically pleasing
> is beyond bizarre, IMO.  If you don't like it, keep it on one line.  If you
> are so offended by it that you cannot stand seeing it, ask your team not to
> do it.  heck, write a script to remove the whitespace upon checkin.  To
> demand the entire world comply.. well, at least remove the B from the title.



I *absolutely* agree. This is too long a discussion on a matter of personal
style, when many other things are much pressing. This isn't even worth
being put into a DEP, in my opinion. It is precisely the sort of small
feature that isn't worth discussing so thoroughly. 70+ e-mails over this
subject is a bit too much, if you ask me. I haven't taken the time to count
the votes, but I would hazard a guess that the score is about +75 vs -3 at
the moment.

The complexity of long tags is going to be present, whether or not we allow
developers to break them into multiple lines. Therefore, the argument
against multiline tags on the currently proposed DEP is absolutely moot.
Even if we account for the fact that developers might find it easier to
write slopping code after we allow for multiline tags, the same could be
said of any other part of Django, so that argument doesn't hold water
either.

Just my 2 cents..


Cheers,
AT

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

Proposal: document and enforce style of all files (including JS, CSS, HTML)

[Trey Hunner]

The JavaScript files use 4 spaces, 2 spaces, or tabs (depending on the
file).  The CSS files use mostly 4 spaces, and the HTML files use mostly 2
spaces and sometimes 4 spaces.

The JavaScript code is unlinted and the general code style is neither
documented nor enforced.  I think jshint should be used for JavaScript
linting and to help clean up the JavaScript code.  It should also be built
into the test process (via running "jshint .").  Optionally, it could also
be run automatically through tox or a fabric/invoke/grunt configuration.

I opened a ticket and pull request related to this issue:
https://code.djangoproject.com/ticket/22463#comment:2

Based on the errors I've seen in the JavaScript code so far, I think a code
review may be sufficient for ensuring that the changed files continue to
work as expected.

-- 
Trey Hunner

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

Re: condition decorator: if-unmodified-since support and updated etags

[Thomas Tanner]

thank you. It's submitted https://github.com/django/django/pull/2573

On 16.04.14 18:24, Tim Graham wrote:
> The mailing list is typically only required for "major" features. I'm
> not entirely sure the extent of what you are proposing, but I don't
> think it'll need a mailing list discussion -- a Trac ticket is sufficient.
> 

-- 
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/534EB557.3020101%40gmx.net.
For more options, visit https://groups.google.com/d/optout.

Re: condition decorator: if-unmodified-since support and updated etags

[Tim Graham]

The mailing list is typically only required for "major" features. I'm not 
entirely sure the extent of what you are proposing, but I don't think it'll 
need a mailing list discussion -- a Trac ticket is sufficient.

On Wednesday, April 16, 2014 12:06:27 PM UTC-4, Thomas Tanner wrote:
>
> Hi Tim, 
> I'm a bit confused by: 
>
> On 16.04.14 16:51, Tim Graham wrote: 
> > https://docs.djangoproject.com/en/dev/internals/contributing/ 
>
> Requesting features: 
> First request the feature on the django-developers list, not in the 
> ticket tracker. It’ll get read more closely if it’s on the mailing list. 
> This is even more important for large-scale feature requests. We like to 
> discuss any big changes to Django’s core on the mailing list before 
> actually working on them. 
>
> If core developers agree on the feature, then it’s appropriate to create 
> a ticket. Include a link the discussion on django-developers in the 
> ticket description. 
>
> As with most open-source projects, code talks. If you are willing to 
> write the code for the feature yourself or, even better, if you’ve 
> already written it, it’s much more likely to be accepted. Just fork 
> Django on GitHub, create a feature branch, and show us your work! 
>
> while in django/CONTRIBUTING.rst: 
>
> **Warning: non-trivial pull requests (anything more than fixing a typo) 
> without Trac tickets will be closed!** `Please file a ticket`__ to 
> suggest changes 
>
> Does this mean the steps are 
> 1. ask on this mailing list whether my feature request is OK 
> 2. create a ticket with the link to discussion 
> 3. create a pull request referencing the ticket 
> Or can I skip step 1, and even step 2? 
>
> thanks 
>
>

-- 
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/2c0211ca-d0d1-4ccc-a0b2-e14c508df80d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[imfletcher]

Judging by some of the comments here, you would think that the request is: 
"everyone MUST break their tags into multiple lines in all cases"

this is a request to support the *optional* ability to break tags across 
lines *in some cases* where it makes sense.  the use cases are clear.  the 
precedent in python is clear.

to say this shouldn't be supported because its not aesthetically pleasing 
is beyond bizarre, IMO.  If you don't like it, keep it on one line.  If you 
are so offended by it that you cannot stand seeing it, ask your team not to 
do it.  heck, write a script to remove the whitespace upon checkin.  To 
demand the entire world comply.. well, at least remove the B from the title.

On Wednesday, April 16, 2014 4:20:08 AM UTC-5, Adam Serafini wrote:
>
> Curtis, I added a thumbnail example to the DEP (pull request in github).
>
>
> On Wed, Apr 16, 2014 at 9:31 AM, Loic Bistuer 
>  > wrote:
>
>> Curtis' branch is now a PR:
>>
>> https://github.com/django/deps/pull/3
>>
>> Feedback is welcome.
>>
>> -- 
>> Loic
>>
>>
>> On Wednesday, April 16, 2014 11:17:58 AM UTC+7, Curtis Maloney wrote:
>>>
>>> Now taking input and feedback:
>>>
>>> https://github.com/funkybob/deps/blob/master/drafts/multiline_tags.rst
>>>  
>>  -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/wRKgnMIhl6g/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/76cf2490-a88e-477f-948d-f15b4018c586%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" 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/eb1549e5-3dfe-460d-8225-13bc5f6b035c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: condition decorator: if-unmodified-since support and updated etags

[Thomas Tanner]

Hi Tim,
I'm a bit confused by:

On 16.04.14 16:51, Tim Graham wrote:
> https://docs.djangoproject.com/en/dev/internals/contributing/

Requesting features:
First request the feature on the django-developers list, not in the
ticket tracker. It’ll get read more closely if it’s on the mailing list.
This is even more important for large-scale feature requests. We like to
discuss any big changes to Django’s core on the mailing list before
actually working on them.

If core developers agree on the feature, then it’s appropriate to create
a ticket. Include a link the discussion on django-developers in the
ticket description.

As with most open-source projects, code talks. If you are willing to
write the code for the feature yourself or, even better, if you’ve
already written it, it’s much more likely to be accepted. Just fork
Django on GitHub, create a feature branch, and show us your work!

while in django/CONTRIBUTING.rst:

**Warning: non-trivial pull requests (anything more than fixing a typo)
without Trac tickets will be closed!** `Please file a ticket`__ to
suggest changes

Does this mean the steps are
1. ask on this mailing list whether my feature request is OK
2. create a ticket with the link to discussion
3. create a pull request referencing the ticket
Or can I skip step 1, and even step 2?

thanks

-- 
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/534EAA83.30609%40gmx.net.
For more options, visit https://groups.google.com/d/optout.

Re: condition decorator: if-unmodified-since support and updated etags

[Tim Graham]

Hi Thomas,

You can read about our contributing process here:
https://docs.djangoproject.com/en/dev/internals/contributing/

In particular, there's a section entitled "Submitting patches".

Tim

On Wednesday, April 16, 2014 9:56:57 AM UTC-4, Thomas Tanner wrote:
>
> Hello, 
> I have implemented support for the If-Unmodified-Since header 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.28 
> in the condition decorator and added an parameter to support updating 
> of the etags for write operations 
> http://tools.ietf.org/id/draft-reschke-http-etag-on-write-09.txt 
>
> Where should I submit my patch? 
>
> cheers, 
>

-- 
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/5b5a0e46-eded-42b2-872a-64168bfe46f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

condition decorator: if-unmodified-since support and updated etags

[Thomas Tanner]

Hello,
I have implemented support for the If-Unmodified-Since header
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.28
in the condition decorator and added an parameter to support updating
of the etags for write operations
http://tools.ietf.org/id/draft-reschke-http-etag-on-write-09.txt

Where should I submit my patch?

cheers,

-- 
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/534E8C29.500%40gmx.net.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Adam Serafini]

Curtis, I added a thumbnail example to the DEP (pull request in github).


On Wed, Apr 16, 2014 at 9:31 AM, Loic Bistuer wrote:

> Curtis' branch is now a PR:
>
> https://github.com/django/deps/pull/3
>
> Feedback is welcome.
>
> --
> Loic
>
>
> On Wednesday, April 16, 2014 11:17:58 AM UTC+7, Curtis Maloney wrote:
>>
>> Now taking input and feedback:
>>
>> https://github.com/funkybob/deps/blob/master/drafts/multiline_tags.rst
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/wRKgnMIhl6g/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/76cf2490-a88e-477f-948d-f15b4018c586%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" 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/CAGxmOQO%3DPK5EnAUtmLLcj6A_aXfMHHp0nKJfsuAfwSz6gEik9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Loic Bistuer]

Curtis' branch is now a PR:

https://github.com/django/deps/pull/3

Feedback is welcome.

-- 
Loic

On Wednesday, April 16, 2014 11:17:58 AM UTC+7, Curtis Maloney wrote:
>
> Now taking input and feedback:
>
> https://github.com/funkybob/deps/blob/master/drafts/multiline_tags.rst
>

-- 
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/76cf2490-a88e-477f-948d-f15b4018c586%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.