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 var
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 because
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 i
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 people serve develop
> 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 just serves them f
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 necessary for some more
>
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 reloade
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
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 4,
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, for
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
Ansible,
>
> 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
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 U
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 ex
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 fr
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
>
> 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 rel
> 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 something, since the development server creates a new
> connect
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 threaded socket server
cre
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, Ada
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 i
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 signals
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
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 code snippet where I l
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 so
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',
'include/sql/materializedviews/latestCo
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 incl
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
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 constrain
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 u
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 template widget rendering wa
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 away from endorsing third
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 rep
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
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, "wee
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 Mc
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, 0.30
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 implementation.
>
> If someone
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, 2017
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 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 -
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 Saifuddin
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 a
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 implementat
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_...
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 3.4+, so you'd need to
> u
46 matches
Mail list logo