Re: Revisiting multiline tags
Let me rephrase -- Where do I voice support that I too would like this feature? Here, on the DEP pull request, on the original ticket? I get that there is a difference between core devs voting and non core devs voicing support, and that +1 from a core dev is a vote whereas +1 from a non-core user is an expression of support. That wasn't the question. The question is about how to most effectively join the chorus so core devs know that people do care about this when they cast their votes. T On Tuesday, April 29, 2014 10:24:12 PM UTC-4, Florian Apolloner wrote: > > Technically I'd think only core devs would vote. So neither here or there > would make a diff imo. > > P.S.: That said I am not sure we have a formal policy on how we act on > DEPs yet (or maybe I should just read DEP 001 more carefully ;)) > > Cheers, > Florian > > On Wednesday, April 30, 2014 4:02:26 AM UTC+2, ted wrote: >> >> Now that there is a DEP, where do we voice our support (cast +1 votes)? >> Here, on the DEP pull request, on the original ticket? >> >> T >> >> On Wednesday, April 16, 2014 10:14:25 PM UTC-4, Loic Bistuer wrote: >>> >>> 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/ef2dc161-3e90-45a9-a1b1-0ab7c61bf41c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Revisiting multiline tags
Now that there is a DEP, where do we voice our support (cast +1 votes)? Here, on the DEP pull request, on the original ticket? T On Wednesday, April 16, 2014 10:14:25 PM UTC-4, Loic Bistuer wrote: > > 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/2fb3d96b-7a31-4cb6-917d-0d92136a71c1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
To be clear, I'm not proposing the settings.py file from my github as a
django default. It is what works for me, provided for context.
Florian, the method you use for environment specific settings is one of the
two most common I saw in my survey: local_settings.py being the most
common. Again, best practice vs common practice I don't know.
But again, I'm not proposing my settings.py file as the default, just
provided for context.
T
On Wednesday, January 2, 2013 4:17:41 PM UTC-5, Florian Apolloner wrote:
>
> Hi,
>
> On Wednesday, January 2, 2013 8:19:36 PM UTC+1, ted wrote:
>>
>> FWIW, this is a working draft of a default settings file I like that
>> addresses most of these issues:
>> https://github.com/tedtieken/django-project-skel/blob/master/project_name/settings.py
>> (would appreciate constructive criticism offline)
>
>
> Luckily you can already use that due to --template support for
> startproject, but here a few comments (Aside from still being violently -1
> on it):
>
> * local_settings is imo a bad pattern as they can't easily override
> anything without copying it completely into the local_settings (think of
> all the settings which are dicts like DATABASES and CACHES)
> * Where does LOCAL_SETTINGS come from, are you supposed to set that in
> your settings file to get locale_settings imported? Why, if local_settings
> are there I want them imported, that is the point of local_settings.
> * All the env configuration stuff is just scary and way to specific for a
> useful default settings file
> * You have way to much stuff in INSTALLED_APPS, most of it is completely
> out of scope for a default settings file.
> * that applib sys.path magic just makes me cry.
>
> That all said, it's nice if that settings file fits you, but I surely
> couldn't do anything with it. This is probably how I would do it (Talking
> about a big monolithic project):
> project/default_settings.py
> test_settings.py
> dev_settings.py
> production_settings.py
>
> then each of the settings files would do: "from project.default_settings
> import *" and then customize stuff as needed (eg: INSTALLED_APPS +=
> ('debug_toolbar',)). This way all the settings files are clearly separated
> and stay readable. Might not be best practices but that's how it works
> quite well for me.
>
> Cheers,
> Florian
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/13cCcVbWiYwJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
> A modern Django project is a collection of apps. Files are looked up under > conventional paths within apps. Modules (especially the settings module) > can live anywhere on $PYTHONPATH. Actually, there's not such thing as a > project root. > > For instance, instead of using TEMPLATE_DIRS, project-wide templates can > go into an "myproject" application. You need one anyway as soon as you > write a custom template tag or filter. > > There are two special cases that don't fit into apps: STATIC_ROOT and > MEDIA_ROOT. (Technically, there's ALLOWED_INCLUDE_ROOTS too, but it isn't > commonly used.) > You can't just say "there is a solution I use, that isn't codified or widely used but solves the problem" and then waive your hand and have the problem go away. TEMPLATE_DIRS, FIXTURES_DIRS, and STATIC_FILES_DIRS are equally special cases unless and until a "project app" is the codified way to do it. Best practice or not, PROJECT_PATH/DIR/ROOT/ETC is common practice to avoid boilerplate. Relative paths for TEMPLATE_DIRS (& others) via Os.Path.Join is a straightforward solution that provides a clean conceptual runway from development to production. Sure the project as a directory analogy isn't a perfect one, but it is a useful first order approximation. For local development, it's certainly fine to store the code in > /home/myproject, compile the static files in /home/myproject/static, and > uploading the media files in /home/myproject/media, and it's convenient to > express that with relative paths. But it's hardly a best practice in > production — at least, not until you've spent 30 seconds thinking about it. > > Django leaves it up to the developer to structure the settings for > different environments. This means we cannot provide a "development only" > settings template. > Django doesn't provide an easy way to distinguish between Dev and Produciton environments (which I think is a separate discussion), Agreed. However, a default that works for development with the information that "you shouldn't do this in production, here's a link to how you should" is far better than nothing. Especially when the nothing is going to lead to people searching for a solution to usually find the default that works for development without the caveat. The current setup gets people to the same "ok for dev" state with more work and less knowledge. I could get behind a proposal to have a "project app" but I'd want to flush out the implications -- right now I'm still +1 on PROJECT_PATH and +0 on "project app". T FWIW, this is a working draft of a default settings file I like that addresses most of these issues: https://github.com/tedtieken/django-project-skel/blob/master/project_name/settings.py (would appreciate constructive criticism offline) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/tw2TfcglfAAJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
> > > The only option I can is whether we put that snippet of code (e.g. > PROJECT_ROOT=os.path.realpath(os.path.dirname(__file__)) ) into the > settings file generated when starting a new project. > +1 for adding this to settings, then adding a commented out os.path.join( PROJECT_ROOT, 'templates') with a brief explanation in the template dirs section, and the same for static. Recently, I went through all of the public startproject templates I could find (and most of their branches): django-project-skel, django-project-skelleton, and django-skel. In all three projects they use some form of PROJECT_ROOT and os.path.join(PROJECT_DIR, 'templates'). https://github.com/amccloud/django-project-skel/blob/master/project_name/settings.py https://github.com/rdegges/django-skel/blob/master/project_name/settings/common.py https://github.com/alex/django-project-skeleton/blob/master/project_name/settings/base.py Lincoln loop has in their best practices as well http://lincolnloop.com/django-best-practices/projects.html#settings I'm under the impression that this is something that nearly everyone does -- are there a large number of cases where people explicitly decide not to use os.path.join and a PROJECT_ROOT variable? Ted -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/VVK1CzrP7AcJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: UPPER vs. ILIKE for __icontains
Yeah, I've played around with the trigram indexes a little in 9.1, with mixed
results. For example, they didn't appear to improve the queries I used in my
examples below.
Anyway, I think the case for using ILIKE for __icontains on postgres is
worthwhile, and it's dead simple to change the 2 lines of code required. I
hope you'll consider it for the next release.
thanks
ted
+
Though apparently pg 9.1's trigram indexes can be used for ILIKE
searches (but aren't a win for all query patterns). It seems to me it'd
be worthwhile to have a setting to tell the backend whether to use ILIKE vs.
LIKE LOWER, though personally I'm not using __icontains so I don't
have a dog in this fight :)
From: Ted Gruenloh <tedgruen...@yahoo.com>
To: "django-developers@googlegroups.com" <django-developers@googlegroups.com>
Sent: Tuesday, October 4, 2011 12:37 PM
Subject: UPPER vs. ILIKE for __icontains
Jonas:
Thanks for the response. The ticket you referenced refers to __iexact. In
that case, I agree with the use of UPPER. My question/suggestion is about
__icontains, which must either use '...LIKE UPPER()' or ILIKE. In my quick
tests, ILIKE wins by about 10% on a table with 1 million records. ILIKE gets
better the more columns you're comparing, too (30% better, in my example). See
my examples below.
Anyway, I changed it in my implementation because it helped significantly in my
specific case. Hope this helps.
thanks
ted
sdb=# explain analyze select * from activity where msg ilike '%exploit abc
akndkf%';
QUERY
PLAN
--
Seq Scan on activity (cost=0.00..42147.00 rows=1 width=192) (actual
time=1802.493..1802.493 rows=0 loops=1)
Filter: ((msg)::text ~~* '%exploit abc akndkf%'::text)
Total runtime: 1802.553 ms
(3 rows)
sdb=# explain analyze select * from activity where upper(msg) like
upper('%exploit abc akndkf%');
QUERY
PLAN
Seq Scan on activity (cost=0.00..44647.00 rows=100 width=192) (actual
time=2074.101..2074.101 rows=0 loops=1)
Filter: (upper((msg)::text) ~~ '%EXPLOIT ABC AKNDKF%'::text)
Total runtime: 2074.158 ms
(3 rows)
sdb=# explain analyze select * from activity where msg ilike '%123%' or
text_src ilike '%123%' or text_dst ilike '%123%' order by msg;
QUERY
PLAN
---
Sort (cost=48622.98..48646.30 rows=9327 width=192) (actual
time=2241.154..2270.481 rows=3774 loops=1)
Sort Key: msg
Sort Method: external merge Disk: 808kB
-> Seq Scan on activity (cost=0.00..47147.00 rows=9327 width=192) (actual
time=11.701..2178.329 rows=3774 loops=1)
Filter: (((msg)::text ~~* '%123%'::text) OR ((text_src)::text ~~*
'%123%'::text) OR ((text_dst)::text ~~* '%123%'::text))
Total runtime: 2298.757 ms
(6 rows)
sdb=# explain analyze select * from activity where upper(msg) like
upper('%123%') or upper(text_src) like upper('%123%') or upper(text_dst) like
upper('%123%') order by msg;
QUERY
PLAN
-
Sort (cost=85617.58..85905.74 rows=115264 width=192) (actual
time=3117.558..3147.699 rows=3774 loops=1)
Sort Key: msg
Sort Method: external merge Disk: 808kB
-> Seq Scan on activity (cost=0.00..54647.00 rows=115264 width=192)
(actual time=8.239..3064.163 rows=3774 loops=1)
Filter: ((upper((msg)::text) ~~ '%123%'::text) OR
(upper((text_src)::text) ~~ '%123%'::text) OR (upper((text_dst)::text) ~~
'%123%'::text))
Total runtime: 3177.240 ms
(6 rows)
- Original Message -
From: Jonas H. <jo...@lophus.org>
To: django-developers@googlegroups.com
Cc:
Sent: Tuesday, October 4, 2011 11:19 AM
Subject: Re:
On 10/04/2011 05:51 PM, Ted Gruenloh wrote:
> The django online documentation mentions that the SQL equivalent for
> __icontains is something like:
>
> SELECT ... WHERE headline ILIKE '%Lennon%';
> However, for postgresql - one of the dbs that actually supports ILIKE - I
> noticed __icontains was actually performing something similar to:
> SELECT ... WHERE LOWER(headline) LIKE LOWER('%Lennon%
UPPER vs. ILIKE for __icontains
Jonas:
Thanks for the response. The ticket you referenced refers to __iexact. In
that case, I agree with the use of UPPER. My question/suggestion is about
__icontains, which must either use '...LIKE UPPER()' or ILIKE. In my quick
tests, ILIKE wins by about 10% on a table with 1 million records. ILIKE gets
better the more columns you're comparing, too (30% better, in my example). See
my examples below.
Anyway, I changed it in my implementation because it helped significantly in my
specific case. Hope this helps.
thanks
ted
sdb=# explain analyze select * from activity where msg ilike '%exploit abc
akndkf%';
QUERY
PLAN
--
Seq Scan on activity (cost=0.00..42147.00 rows=1 width=192) (actual
time=1802.493..1802.493 rows=0 loops=1)
Filter: ((msg)::text ~~* '%exploit abc akndkf%'::text)
Total runtime: 1802.553 ms
(3 rows)
sdb=# explain analyze select * from activity where upper(msg) like
upper('%exploit abc akndkf%');
QUERY
PLAN
Seq Scan on activity (cost=0.00..44647.00 rows=100 width=192) (actual
time=2074.101..2074.101 rows=0 loops=1)
Filter: (upper((msg)::text) ~~ '%EXPLOIT ABC AKNDKF%'::text)
Total runtime: 2074.158 ms
(3 rows)
sdb=# explain analyze select * from activity where msg ilike '%123%' or
text_src ilike '%123%' or text_dst ilike '%123%' order by msg;
QUERY
PLAN
---
Sort (cost=48622.98..48646.30 rows=9327 width=192) (actual
time=2241.154..2270.481 rows=3774 loops=1)
Sort Key: msg
Sort Method: external merge Disk: 808kB
-> Seq Scan on activity (cost=0.00..47147.00 rows=9327 width=192) (actual
time=11.701..2178.329 rows=3774 loops=1)
Filter: (((msg)::text ~~* '%123%'::text) OR ((text_src)::text ~~*
'%123%'::text) OR ((text_dst)::text ~~* '%123%'::text))
Total runtime: 2298.757 ms
(6 rows)
sdb=# explain analyze select * from activity where upper(msg) like
upper('%123%') or upper(text_src) like upper('%123%') or upper(text_dst) like
upper('%123%') order by msg;
QUERY
PLAN
-
Sort (cost=85617.58..85905.74 rows=115264 width=192) (actual
time=3117.558..3147.699 rows=3774 loops=1)
Sort Key: msg
Sort Method: external merge Disk: 808kB
-> Seq Scan on activity (cost=0.00..54647.00 rows=115264 width=192)
(actual time=8.239..3064.163 rows=3774 loops=1)
Filter: ((upper((msg)::text) ~~ '%123%'::text) OR
(upper((text_src)::text) ~~ '%123%'::text) OR (upper((text_dst)::text) ~~
'%123%'::text))
Total runtime: 3177.240 ms
(6 rows)
- Original Message -
From: Jonas H. <jo...@lophus.org>
To: django-developers@googlegroups.com
Cc:
Sent: Tuesday, October 4, 2011 11:19 AM
Subject: Re:
On 10/04/2011 05:51 PM, Ted Gruenloh wrote:
> The django online documentation mentions that the SQL equivalent for
> __icontains is something like:
>
> SELECT ... WHERE headline ILIKE '%Lennon%';
> However, for postgresql - one of the dbs that actually supports ILIKE - I
> noticed __icontains was actually performing something similar to:
> SELECT ... WHERE LOWER(headline) LIKE LOWER('%Lennon%');
>
> The ILIKE is obviously much faster [...]
https://code.djangoproject.com/ticket/3575
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
[no subject]
All:
I'm not a Django developer, nor will I pretend to be. But I did come across
something I thought you should be aware of.
The django online documentation mentions that the SQL equivalent for
__icontains is something like:
SELECT ... WHERE headline ILIKE '%Lennon%';
However, for postgresql - one of the dbs that actually supports ILIKE - I
noticed __icontains was actually performing something similar to:
SELECT ... WHERE LOWER(headline) LIKE LOWER('%Lennon%');
The ILIKE is obviously much faster, so, I dug around a little and changed a
line or two in these files:
/usr/local/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py
/usr/local/lib/python2.7/site-packages/django/db/backends/postgresql/operations.py
...so __icontains actually uses ILIKE instead, and it's running great.
OK:
1) Any reason I shouldn't have done that, performance wise?
2) Should this be changed in the codebase going forward?
thanks, and I hope this helps,
ted
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Newforms: colon after label
Were I work we have had to do this very thing to support I18N in our forms. Something as simple as a ":" is not a given. Maybe I want a " :" instead? This could be a form parameter or even a locale setting. My 2 cents, Ted On Mar 29, 9:10 am, "Todd O'Bryan" <[EMAIL PROTECTED]> wrote: > On Thu, 2007-03-29 at 13:02 +, Jonas Maurus wrote: > > > I think there are lots of situations where you need to normalize the > > > labels with some string. Why not just make it an optional parameter to > > > the Form class with a default value.. maybe ":"? > > > > Rune > > > so that would make > > >name = forms.CharField(label='What role do you want to play?') > > > into > > > name = forms.CharField(label='What role do you want to play', > > punctuation='?') > > > for *sometimes* saving you from typing one character? I still think it > > makes no sense to append anything at all. Not to mention the pending > > unicodization... the Japanese, Chinese, Korean and Cyrillic alphabets > > don't use western punctuation... > > > Unless there's a better argument than sometimes saving one character > > or being backwards-compatible to 0.96, I'm still against this. > > However, I don't carry much weight around here ;-) > > I think he was suggesting in the form, not each field: > > form = forms.Form(punct='') > > would let you create a form with no colons. You could also do something > like > > form = forms.Form(punct='-->') > > or whatever. This would also allow you to override the punctuation based > on locale. Seems like a not bad solution. People who hate the colons > could create their own subclass of Form and use it instead of the > default form and then they wouldn't have to set the punct value each > time. > > Todd --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Cheat Sheet
Excellent John Thanks! As we approach 0.96 any chance of getting a pre-release newforms based version? Ted On Feb 13, 5:24 am, "John Sutherland" <[EMAIL PROTECTED]> wrote: > Hi all, > > Firstly, sorry for the cross-post. > > My employer, Mercurytide [1], as some of you may have seen in the > past, publishes white-papers on a monthly basis. This month it's > another Django themed one: a Django cheat sheet: > > <http://www.mercurytide.com/whitepapers/django-cheat-sheet/> > > We've spent a fair bit of time on it and would really appreciate the > following: > > 1. That you download it; try it out and enjoy it! > 2. Give us feedback, we know it's not going to be perfect first time, > so let us know: [EMAIL PROTECTED] > 3. You publicise it: it would be awesome to get it on the digg front > page [2]; but put it on your blog, your del.icio.us or where ever... > > Cheers, > John. > > [1] <http://www.mercurytide.com/> > [2] <http://digg.com/programming/Django_cheat_sheet> > > -- > [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
