Re: Template handling of undefined variables

Hi Tim, On 01/04/2017 03:39 PM, Tim Martin wrote: > I've been looking at bug #24977 (Template variables with a value of > None are considered to be == to non-existent properties). ... > The suggestion on the ticket is to use an instance of a special > `Undefined` class to indicate an undefined

Template handling of undefined variables

Hi all, I've been looking at bug #24977 (Template variables with a value of None are considered to be == to non-existent properties). The problem is that in a template: {% if user.pk == some_object.invalid_property %} ... this gets rendered when the user is logged out {% endif %} This is

Re: Should we add a dependency on the multipledispatch library, or vendor it?

It seems everyone that has chimed in prefers adding a dependency to vendoring. If there are alternative views please express them, but I'm going to recommend a dependency on the PR. Thanks On Tuesday, 3 January 2017 09:13:01 UTC+11, Josh Smeaton wrote: > > I agree with Tim. I think the intent

Re: Add custom autoreload file tracking options setting

No, there's a cached template loader: https://docs.djangoproject.com/en/dev/ref/templates/api/#django.template.loaders.cached.Loader On Wednesday, January 4, 2017 at 7:00:31 PM UTC-5, Bobby Mozumder wrote: > > > On Jan 4, 2017, at 5:40 PM, Adam Johnson > wrote: > > How do

Re: Add custom autoreload file tracking options setting

> On Jan 4, 2017, at 5:40 PM, Adam Johnson wrote: > > How do people serve development Javascript & CSS files? These days > Javascript & CSS involves a large build process. Are we forced to manually > restart the development server every time Javascript changes? > > Django

Re: Changing {% include %} to strip a trailing newline

Actually you're right it's probably the same > Or do you propose to strip only exactly one trailing newline character? I thought the proposal was only for exactly one On Wed, 4 Jan 2017 at 23:17, Tim Graham wrote: > About "the backwards compatible option is probably

Re: Future of the development server's auto-reloading

So this idea doesn't get lost, I created a ticket for "Allow autoreloader to use watchman" https://code.djangoproject.com/ticket/27685#ticket On Monday, June 27, 2016 at 8:23:05 PM UTC-4, Tim Graham wrote: > > A pull request is proposed to add a new setting to allow specifying a > custom

Re: django-formtools is neglected/unmaintained

Thanks a lot, Tim! If you think I could help, then let me know. Otherwise, I'll just stay out of your way :) On Wednesday, January 4, 2017 at 4:02:29 PM UTC-7, Tim Graham wrote: > > According to https://github.com/django/django-formtools/issues/75, > there's a change in master that's needed for

Re: Changing {% include %} to strip a trailing newline

About "the backwards compatible option is probably necessary for some more advanced uses of templates out there, e.g. templating whitespace sensitive file formats." -- I'm not following why a similar find/replace approach wouldn't be sufficient to adapt those templates? On Wednesday, January

Re: Changing {% include %} to strip a trailing newline

On 01/04/2017 02:53 PM, Tim Graham wrote: > I'd like to know from Carl, Adam, and others, how much effort would be > required to adapt the templates in your project for the new behavior. I > imagine a script could be written to add newlines after all {% include > %} in all plain text templates,

Re: Changing {% include %} to strip a trailing newline

On 05/01/17 10:09, Adam Johnson wrote: Whitespace control in templates is an exercise in frustration. In my experience more flexible tools such as {%-, {%+, -%}, and +%} in Jinja2 increase the frustration. I really enjoy the {%- etc. operators in Jinja 2 in the context of

Re: Changing {% include %} to strip a trailing newline

> > Whitespace control in templates is an exercise in frustration. In my > experience more flexible tools such as {%-, {%+, -%}, and +%} in Jinja2 > increase the frustration. I really enjoy the {%- etc. operators in Jinja 2 in the context of Ansible, there are often cases when templating obscure

Re: django-formtools is neglected/unmaintained

According to https://github.com/django/django-formtools/issues/75, there's a change in master that's needed for 1.10 compatibility. I'll try to do a release if I can get access to the PyPI record. I pinged the owner (jezdez) in #django-dev about it. On Wednesday, January 4, 2017 at 5:51:56 PM

Re: Changing {% include %} to strip a trailing newline

Aymeric, we have a difference of opinion. I feel that if {% include %} removed the trailing newline, it would result in far more intuitive whitespace control (which may be needed in plain text email templates, for example). I think the change has merits outside the context of this issue. For

Re: django-formtools is neglected/unmaintained

1) Tim added testing on Django 1.10 in July 2016, it seems to work? https://github.com/django/django-formtools/commits/master 2) New contributors are always welcome 3) I don't know of other packages, you can check https://djangopackages.org/ 4) It's true that many websites are built with pure JS

Re: django-formtools is neglected/unmaintained

Hi Tim, You make some good points. Basically, my situation is that I want to use some features of Django v1.10 for a project at my company, but I am unable to because I use django-formtools for a FormPreview, and it is not compatible with v.1.10. I am also worried about using Django for future

Re: Add custom autoreload file tracking options setting

> > How do people serve development Javascript & CSS files? These days > Javascript & CSS involves a large build process. Are we forced to manually > restart the development server every time Javascript changes? Django just serves them from the filesystem, and doesn't cache them itself. You

Re: Add custom autoreload file tracking options setting

> On Jan 4, 2017, at 4:47 PM, Aymeric Augustin > wrote: > > Hello Bobby, > >> On 4 Jan 2017, at 22:25, Bobby Mozumder wrote: >> >> It’s actually called once on app startup during DB connection via a Signal. > > Unless I missed

Re: Add custom autoreload file tracking options setting

Hello Bobby, > On 4 Jan 2017, at 22:25, Bobby Mozumder wrote: > > It’s actually called once on app startup during DB connection via a Signal. Unless I missed something, since the development server creates a new connection to the database for each request — Python’s

Re: Add custom autoreload file tracking options setting

That’ll make development server access times really slow. There’s a pretty long Makefile also that builds Javascript. We really shouldn’t have to rebuild Javascript on every page view, especially since I call interactive API requests with these views. -bobby > On Jan 4, 2017, at 4:18 PM,

Re: Changing {% include %} to strip a trailing newline

If I understand correctly, we have to choose between: 1. breaking backwards compatibility for {% include %} 2. breaking backwards compatibility for widgets HTML 3. having a handful of single-line, non-newline-terminated files I don’t think option 1 is reasonable. Whitespace control in templates

Re: Add custom autoreload file tracking options setting

It’s actually called once on app startup during DB connection via a Signal. Here is my app.py: from django.apps import AppConfig from .signals import * from django.utils import autoreload class FashionAppConfig(AppConfig): name = 'fashion' verbose_name = "Fashion" And here is my

Re: Changing {% include %} to strip a trailing newline

Tim, yes I meant the keep_trailing_newline option. Digging through the code (as I mentioned on IRC), it's possible to have the form rendering to use different options. Here is a proof of concept [0], which forces removal of trailing whitespace in forms, and adds it as an option for settings. I'm

Re: Add custom autoreload file tracking options setting

For that use case I'd suggest just re-executing prepare_db_queries on every page view when DEBUG=True. This is similar to how Django's template loaders work without the cached loader wrapping them. On 4 January 2017 at 21:12, Bobby Mozumder wrote: > OK here is some example

Re: Add custom autoreload file tracking options setting

When is prepare_db_queries() called? During a request/response cycle? I doesn't look like any caching is happening so I still doesn't see why the server needs to restart to pickup changes to the SQL files. On Wednesday, January 4, 2017 at 4:12:27 PM UTC-5, Bobby Mozumder wrote: > > OK here is

Re: Add custom autoreload file tracking options setting

OK here is some example code snippet where I load prepared SQL statements: class FastDetailView(DetailView,FastView): c = connection.cursor() SQL_VIEW_DIRS = { 'fashion': ( 'include/sql/materializedviews/headlines',

Re: Add custom autoreload file tracking options setting

Could you give us a code snippet (sample view, perhaps) demonstrating how this caching happens? On Wednesday, January 4, 2017 at 3:57:31 PM UTC-5, Bobby Mozumder wrote: > > Hi, > > Right now, Django only tracks Python module files for autoreload during > development. As a project starts to

Add custom autoreload file tracking options setting

Hi, Right now, Django only tracks Python module files for autoreload during development. As a project starts to include more custom include files, such as Javascript, SQL, Makefiles, etc.., the autoreload function doesn't apply to these. For my use case, I have custom view functions that call

Re: Changing {% include %} to strip a trailing newline

Anthony, I assume you're referring to the keep_trailing_newline option? If we don't enable it for existing projects, then forms will render with extra newlines. I think it's better to have projects opt-out of the behavior if they're unable to audit their non-HTML templates due to time

Re: Changing {% include %} to strip a trailing newline

Could this be set within the template rather than the include tag? So for example have a new tag such as {% strip_final_new_line %} that when included at the end of a template immediately before the final new line would instruct it to be striped. This stops the user from having to remember to

Re: Changing {% include %} to strip a trailing newline

I think adding the option would be the better approach, and add it in as default for new projects. Having used templates for text emails, I do find it unintuitive to write them because of the newline behaviour. On 4 Jan 2017 19:58, "Tim Graham" wrote: > Shortly after

Re: Working towards a simpler GCBV implementation?

Fair enough, there are other community resources for this. The PR adding a pointer in the docs to ccbv.co.uk in https://github.com/django/django/pull/7785 is a good idea that came from this thread though. On 4 January 2017 at 13:08, Tim Graham wrote: > We typically shy

Changing {% include %} to strip a trailing newline

Shortly after template widget rendering was merged, an issue about extra newlines appearing in the rendered output was reported [0]: For example, from django-money: UIC-Franc \n\n US Dollar \n\n The newlines aren't useful and they break assertions like this: US Dollar in form.as_p --- end

[ANNOUNCE] Django bugfix release: 1.10.5

Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2017/jan/04/bugfix-release/ -- 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

Re: Methodology for increasing the number of PBKDF2 iterations

If anyone is curious about the breakdown of versions, I used the following query: SELECT REGEXP_EXTRACT(details.python, r"^([^\.]+\.[^\.]+\.[^\.]+)") as python_version, COUNT(*) as download_count, FROM TABLE_DATE_RANGE( [the-psf:pypi.downloads], DATE_ADD(CURRENT_TIMESTAMP(), -2,

Re: Methodology for increasing the number of PBKDF2 iterations

I think this is a pretty solid guess. Bear in mind this was a direct install from Python.org. The important thing here is, this demonstrates that we cannot just assume that all Python 3 installs have a "fast" PBKDF2 implementation =/ On Wednesday, January 4, 2017 at 11:33:17 AM UTC-5, Tobias

Performance limits for large number of sites? (tenants/saas offering)

I love how Django CMS handles the concept of "pages", breaking them into placeholders/plugins with a nice workflow, while deferring data modelling to Django. I am considering using it for a SaaS offering, in which each tenant would get their own "site". So there would be hundreds, possibly

Re: Methodology for increasing the number of PBKDF2 iterations

Okay, for good measure, here's with 2.7.7. And yeah, looks like almost 4x slower. Python: 2.7.7, Django: 1.10.4 Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes, on average, 0.3050s Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes, on average,

Re: Methodology for increasing the number of PBKDF2 iterations

Thanks Alex, TIL https://mail.python.org/pipermail/distutils-sig/2016-May/028986.html On 4 January 2017 at 17:42, Alex Gaynor wrote: > Python 2.7.12 will look the same as 3.5.x, they both have the optimized > implementation. Only 2.7.X where X<8 will have the slow

Re: Methodology for increasing the number of PBKDF2 iterations

Python 2.7.12 will look the same as 3.5.x, they both have the optimized implementation. Only 2.7.X where X<8 will have the slow implementation. If someone was motivated, they could look at the PyPI bigquery and see what versions of 2.7 people are using to install django. Alex On Wed, Jan 4,

Re: Methodology for increasing the number of PBKDF2 iterations

FWIW, here are my own results from that benchmark (I ran each 5 times just to account for any other system activity): Python: 2.7.12, Django: 1.10.4 Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes, on average, 0.0884s Using cipher: "pbkdf2_sha256" with 100,000

Re: Methodology for increasing the number of PBKDF2 iterations

Here's an interesting tidbit from Alex Gaynor in 2014: https://github.com/django/django/commit/6732566967888f2c12efee1146940c85c0154e60#diff-dd9c116fcefaf3916ace2608656311e0 It's worth noting that, if I'm understanding this correctly, there are two slow versions of pbkdf2 we have to worry about

Re: Working towards a simpler GCBV implementation?

We typically shy away from endorsing third-party libraries in the Django docs. I don't think it makes much sense to stay something to the effect of "The built-in views are too complex so we recommend using other library instead." On Wednesday, January 4, 2017 at 7:30:54 AM UTC-5, Asif

Re: Error after installing django-tracking2 package for tracking user activity

Hi, This mailing list for for discussing the development of django internals. For your queries please post in django-users list. Thanks On Wednesday, January 4, 2017 at 6:30:33 PM UTC+6, Gunwant Suryawanshi wrote: > > Hi, > I am trying to track user activity on my website, for that purpose I

Re: Working towards a simpler GCBV implementation?

Hi, I will update the doc pointing vanilla views as simpler alternative implementation. Thanks On Tuesday, January 3, 2017 at 7:20:24 PM UTC+6, Adam Johnson wrote: > > I think this is probably too disruptive a change for Django core, > especially after so long with the current GCBV

Error after installing django-tracking2 package for tracking user activity

Hi, I am trying to track user activity on my website, for that purpose I am using django-tracking2 package. But after successfully installation I am getting following error:- relation "tracking_visitor" does not exist LINE 1: ...time_on_site", "tracking_visitor"."end_time" FROM "tracking_...

Re: Methodology for increasing the number of PBKDF2 iterations

Still, this benchmark shows Python 3.5 being 3 times slower than Python 2.7. This is a surprisingly large regression for this time-sensitive function. -- Aymeric. > On 4 Jan 2017, at 02:06, Tim Graham wrote: > > The PBKDF2 speed improvements are in Python 2.7.8 and