I am not sure what the policy is for components with such strong
restrictions. So I guess this is a question back to the group:
What are requirements for components within Django with regard to system
architecture? Are components required to work on distributed systems?
If there is no general ans
If most everyone agrees that Tom's Vanilla Views are superior than what's
currently in core, maybe the path forward is to integrate into 2.0?
On Wednesday, January 4, 2017 at 3:00:03 PM UTC-5, Adam Johnson wrote:
>
> Fair enough, there are other community resources for this.
>
> The PR adding a p
Hi,
On Thursday, 5 January 2017 17:51:39 UTC, Tim Martin wrote:
>
>
>
> On Thursday, 5 January 2017 04:15:31 UTC, Carl Meyer wrote:
>>
>> Hi Tim,
>>
>> On 01/04/2017 03:39 PM, Tim Martin wrote:
>>
>> > 1) There are test cases where we have templates that should treat "x
>> >is y" as True
>
> I apologise if adding the tests has made it harder to improve the
> behaviour of the tag.
I don't think you have anything to apologise for! More tests is always
better. This has clarified the current behaviour 👌
On 6 January 2017 at 10:15, Alasdair Nicol wrote:
> Hi,
>
> On Thursday, 5 Jan
On Friday, January 6, 2017 at 11:11:37 AM UTC+1, Alex Scott wrote:
>
> If most everyone agrees that Tom's Vanilla Views are superior than what's
> currently in core, maybe the path forward is to integrate into 2.0?
>
2.0 is not going to be as backwards incompatible as you might, it is mainly
2.0
After thinking a bit more: Are there any concrete reasons to drop 3.4/3.5
aside from new features? Sure, security is an issue, but looking at the
issues with cookie parsing we would have been better off by immediately
fixing ourself instead of waiting for python (same goes for XML). So in the
e
"EDIT://" Oh, and while it is true that it is a bit more work for us to
support multiple python versions, I've never seen it that bad. Installing
more CI runners which have the matching python versions does not hurt that
much either. Actually it might nowadays even be easier on CentOS than on
U
On Fri, Jan 6, 2017, Florian Apolloner wrote:
>In the end (in my experience), people are using Django everywhere and part
>of the usage also comes from the fact that it's not that hard to deploy for
>sysadmins since python is available anywhere; compiling a new Python +
>infrastructure around
Hello,
I agreed with Florian and Daniele. Python 3.4 will be supported until March
2019, giving it over 1 year of overlap with Django 2.0, including the entire
mainstream support period.
I don’t expect supporting Python 3.4 to be a burden or dropping it to allow
large gains. The language-level
So you all want to do a one time exception to our guidance of of "Typically
we will support a Python version up to and including the first Django LTS
release whose security support ends after security support for that version
of Python ends." and support Python 3.4 for how long? Or revise the
g
I'd like to merge the current patch that removes the trailing newline in
the attrs.html template, then revisit the issue of {% include %} stripping
the trailing newline for the next version of Django so we don't need to
rush a decision about that.
On Thursday, January 5, 2017 at 10:05:30 AM UTC
On Friday, January 6, 2017 at 3:13:27 PM UTC+1, Tim Graham wrote:
>
> I'd like to merge the current patch that removes the trailing newline in
> the attrs.html template, then revisit the issue of {% include %} stripping
> the trailing newline for the next version of Django so we don't need to
On Thu, Jan 5, 2017 at 8:10 PM, Asif Saifuddin wrote:
> Hi,
>
> django 2.0 will be released in december 2017 and ubuntu 18.04 will be
> released in april 2018 which will default atleast 3.6, so I think this
> should also be taken as consideration while deciding.
I know supporting endless versions
Tom, I'm not following how Python 3.4 support in Django 2.0 will benefit
you if you want to stick to LTS versions of Django? I think either you or I
have a misunderstanding somewhere. I'll try to recap:
Django 1.11 is the next LTS. It's supported until April 2020 and supports
Python 3.4. The ne
As part of removing inline JavaScript in the admin [0], snippets such as
document.getElementById("id_old_password").focus() were replaced with the
HTML5 autofocus attribute.
This attribute has a possibly undesired behavior [1]: "*Warning*: this
attribute will force a page scroll to the field wi
I think we should remove it and maybe add the Javascript back, this is
going to affect many peoples' workflows, some of whom are in my
organization.
On Friday, January 6, 2017 at 5:48:12 PM UTC, Tim Graham wrote:
>
> As part of removing inline JavaScript in the admin [0], snippets such as
> doc
On Fri, Jan 6, 2017 at 12:48 PM, Tim Graham wrote:
> Do you think we should remove autofocus from the search box to remedy this
> complaint (and possibly go back to using JavaScript for that) or are there
> any better solutions here?
I personally find the existing auto-focus behavior more annoy
I just posted this and I didn't see it pop up in the group, so I am sorry
if this is a repost.
I recently submitted a bad fix
(https://code.djangoproject.com/ticket/27686#comment:6). I made a mistake
in thinking about how the caching system works but I think I have another
solution to the pro
I recently proposed a bad fix (https://code.djangoproject.com/ticket/27686) but
I think the problem still remains and I might have a way arpund it.
I understand that calling is_authenticated on a user will require the session
to be accessed and the vary by cookie header to be in the response, bu
It is a repost, let's use the first post:
https://groups.google.com/d/msg/django-developers/4kwZP8Rq5IU/rQi5GgI6DgAJ
All first time posters go through a moderation queue.
On Friday, January 6, 2017 at 9:50:56 PM UTC-5, Jeff Willette wrote:
>
> I just posted this and I didn't see it pop up in the
Hi Jeff,
On 01/06/2017 06:21 PM, Jeff Willette wrote:
> I understand that calling is_authenticated on a user will require the
> session to be accessed and the vary by cookie header to be in the
> response, but if I understand how caching systems work then this will
> cause all cookies in the reque
I don't know if matters to anyone, but I guess as long as we support Python
3.4 we can't do the type hinting project (PEP 484) since that's new in 3.5?
On Friday, January 6, 2017 at 12:08:07 PM UTC-5, Tim Graham wrote:
>
> Tom, I'm not following how Python 3.4 support in Django 2.0 will benefit
On Fri, Jan 6, 2017 at 7:03 PM Tim Graham wrote:
> I don't know if matters to anyone, but I guess as long as we support
> Python 3.4 we can't do the type hinting project (PEP 484) since that's new
>
> The typing module also exists standalone on PyPI and thus is pip
> installable for Python 3 < 3.
Carl, thanks for the reply.
Wy would this not help the efficiency of the downstream caches? Is it
because the request has already passed through them with the cookies
intact? and when it comes back through the response they have no way to
know they have been stripped?
On Saturday, January 7,
24 matches
Mail list logo
