On Thursday, January 5, 2017 at 11:14:08 PM UTC+1, Josh Smeaton wrote:
>
> > I am -0 to -1 for the debugger -- I've seen to many sites out there
> running with DEBUG=True, enabling RCE ootb seems to be pretty horrible.
>
> But it's so incredibly useful. And we already show the django debug page
> I am -0 to -1 for the debugger -- I've seen to many sites out there
running with DEBUG=True, enabling RCE ootb seems to be pretty horrible.
But it's so incredibly useful. And we already show the django debug page
for errors with DEBUG=True that exposes enough secrets to allow a
sufficient att
Hi Asif,
On Thursday, January 5, 2017 at 9:10:40 PM UTC+1, Asif Saifuddin wrote:
>
> 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.
>
What come
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.
Thanks
On Wednesday, January 4, 2017 at 1:00:00 AM UTC+6, Tim Graham wrote:
>
> August 2016: P
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 where x and y are both undefined.
>
> Really? Is this an accidental side effe
Slightly off-topic, this presents a really nice case for switching to
Argon2 via argon2_cffi (supported in Django 1.10+). Its super fast (C-lib)
and resistant to GPU/ASIC brute-forcing. So, where as an attacker's 8-GPU
hashing machine would probably have something on the order of 24,000X more
h
I’m -0 on the change. I could move to +0 if I understood why the use
case described here requires watching additional files.
A different use case we've run into is non-python configuration files.
Our settings.py reads a few variables off a toml file and it would be
nice if we could configure r
Would adding the future include tag to the builtins in the template OPTIONS
work? If it did, then you'd only have to make the change to the TEMPLATES
setting instead of every template.
OPTIONS={
'builtins': ['django.template.future_include'], # put new include
in it's own module so
Hi Simon, I mentioned that idea offhand in an earlier mail, however, I feel
that it would be really disruptive to force all projects to go through that
deprecation and require adding {% load include from future %} to every
template that uses the tag to silence warnings (and then remove those lin
On Thu, Jan 5, 2017 at 8:06 AM Florian Apolloner
wrote:
>
>
> On Thursday, January 5, 2017 at 1:38:44 PM UTC+1, Sam Willis wrote:
>
> Could one options be to replace the current devserver with the one from
> Werkzeug? It already uses watchdog (similar to watchman) for monitoring
> file system eve
Hey Tim,
I just wanted to mention that another approach for a transition plan could
be
to use {% load include from future %} like we did with the {% url %} tag.
That doesn't answer the question of whether or not we should make the change
but I think it offers a better upgrade path than a global
On Thursday, January 5, 2017 at 1:38:44 PM UTC+1, Sam Willis wrote:
>
> Could one options be to replace the current devserver with the one from
> Werkzeug? It already uses watchdog (similar to watchman) for monitoring
> file system events and is well maintained. With Django now allowing
> depe
Could one options be to replace the current devserver with the one from
Werkzeug? It already uses watchdog (similar to watchman) for monitoring
file system events and is well maintained. With Django now allowing
dependancies, this seems like something that doesn't necessarily need to be
develop
Hi guys,
I'm currently investing some efforts to clean and make some django packages
up-to-date.
After django-dirtyfields (https://github.com/romgar/django-dirtyfields),
I'm now beginning to work on django-model-utils
(https://github.com/carljm/django-model-utils) where there is some work to
u
On 4 Jan 2017, at 23:31, Bobby Mozumder wrote:
> I guess I could just use Watchman to restart the Django development server as
> needed?
If you find a way to tell watchman to run `django-admin runserver --noreload`
and restart it whenever a file in the current directory changes, that should d
Hello,
I’m not going to veto whitespace control in Django templates. Mostly I’m
uncomfortable with rushing this feature to fix the much narrower problem
discussed here.
If we want to provide whitespace control in templates, we should review use
cases, other implementations, and figure out some
16 matches
Mail list logo
