Re: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)
Mike Scott wrote: Marty: If you read his post you'll see he is infact getting a 500 Server error, and not a spam filter error. 500 Server errors happen when something goes wrong, not when spam is filtered. The way that this ticket system is set up, you do indeed get a 500 Server error when you are marked as spam; pasted: Internal Server Error 500 Internal Server Error (Submission rejected as potential spam (Akismet says content is spam)) TracGuide — The Trac User and Administration Guide This is re-creatable by simply being anonymous (clear your cookies, or use a different browser!) and attempting to post a ticket. Jeff Anderson signature.asc Description: OpenPGP digital signature
Re: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)
Marty: If you read his post you'll see he is infact getting a 500 Server error, and not a spam filter error. 500 Server errors happen when something goes wrong, not when spam is filtered. On Thu, Jun 5, 2008 at 5:40 AM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > On Wed, Jun 4, 2008 at 1:21 PM, Aral Balkan <[EMAIL PROTECTED]> wrote: > > Unfortunately, I don't think your ticketing system likes me. I'm > > getting: 500 Internal Server Error (Submission rejected as potential > > spam). > > Right on the new ticket screen, under the big heading labeled "Read > this first" you'll find the following line: > > "If you're getting rejected by the spam filter, we apologize! The best > way to avoid that is to register for an account and make sure you're > logged in." > > -Gul > > > > --~--~-~--~~~---~--~~ 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: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)
On Wed, Jun 4, 2008 at 1:21 PM, Aral Balkan <[EMAIL PROTECTED]> wrote: > Unfortunately, I don't think your ticketing system likes me. I'm > getting: 500 Internal Server Error (Submission rejected as potential > spam). Right on the new ticket screen, under the big heading labeled "Read this first" you'll find the following line: "If you're getting rejected by the spam filter, we apologize! The best way to avoid that is to register for an account and make sure you're logged in." -Gul --~--~-~--~~~---~--~~ 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: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)
Hi Russell,
Unfortunately, I don't think your ticketing system likes me. I'm
getting: 500 Internal Server Error (Submission rejected as potential
spam).
Here's the text of the ticket. If anyone can post it up for me, I'd be
grateful. Thanks!
Aral
The truncatewords filter currently adds faux ellipses (three dots) to
every truncated string. This is not ideal for several reasons:
1. It should use a true ellipsis (\u2026) instead of three dots.
2. The filter would be far more useful if adding ellipses was an
_option_.
Use case for number 2:
I have a person's full name: "Aral Balkan" and I want to greet them
by their first name. I should be able to write the following in a
template to indicate that an ellipsis should not be added:
{{{
Hello, {{personName|truncatewords:1:False}}, how are you?
}}}
The truncatewords filter would simply have its signature altered and
call utils.text.truncate_words with the altered signature, passing the
second argument:
{{{
def truncatewords(value, arg, add_ellipsis=True):
"""
Truncates a string after a certain number of words.
Argument: Number of words to truncate after. And, (optional)
whether or not to add an ellipsis.
"""
from django.utils.text import truncate_words
try:
length = int(arg)
except ValueError: # Invalid literal for int().
return value # Fail silently.
return truncate_words(value, length, add_ellipsis)
}}}
And utils.text.truncate_words would be changed to:
{{{
def truncate_words(s, num, add_ellipsis=True):
"Truncates a string after a certain number of words."
s = force_unicode(s)
length = int(num)
words = s.split()
if len(words) > length:
words = words[:length]
if add_ellipsis:
if not words[-1].endswith(u'…'):
words.append(u'…')
return u' '.join(words)
}}}
Since we're using a unicode literal, utils.text would also have to
specify the encoding:
{{{
# This Python file uses the following encoding:
utf-8
}}}
Unfortunately, we don't have multiple arguments in filters, so the
above will not currently work. However, because this is an actual use
case, I do need to implement this somehow and my options are either
to:
1. Handle the truncation in my view and pass only the first name. This
leads to duplication of code. And it's debatable how much this code
actually belongs in my view function.
2. Write a separate filter (truncatewordswithoutellipsis) with an
inelegant name and result in duplication of code.
3. Have truncatewords accept a string and parse it using a delimiter.
(If having multiple arguments is seen an overly-complex for filters,
this is doubly so as it makes the syntax way more confusing by robbing
the integer length argument and the boolean add_ellipsis argument of
their actual datatypes and thus weakening the intent of the code).
4. Create a convention that works with the current system and only
requires one argument.
In this case, I decided to go with number 4 and create the following
convention:
If the argument provided to truncatewords is positive, it ads
ellipsis, if it is negative, it does not.
{{{
Hello, {{personName|truncatewords:1}},
}}}
Hello, Aral ...,
{{{
Hello {{personName|truncatewords:"-1"}},
}}}
Hello, Aral,
Of course, this solution is quite ridiculous and the syntax is in no
way intuitive. It is a direct result of the artificial constraint of
not being able to use more than one argument in a filter (and not the
template-author's needs). Within the current rules for filters,
however, it makes complete sense and may even be seen as an elegant
solution given the one-argument constraint (which is to say that, ipso
facto, the current constraint does not make much sense.)
I am aware of and completely agree with Django's philosophy of keeping
templates simple but, in this case, the limitation of having just one
argument for a filter actually _complicates_ templates more than if
filters could take more than one argument.
The refactored truncatewords filter from the solution above is below
and uses the utils.text.truncate_words function listed earlier:
{{{
def truncatewords(value, arg, add_ellipsis=True):
"""
Truncates a string after a certain number of words.
Argument: Number of words to truncate after. And, (optional)
whether or not to add an ellipsis.
"""
from django.utils.text import truncate_words
try:
length = int(arg)
except ValueError: # Invalid literal for int().
return value # Fail silently.
if length<0:
add_ellipsis = False;
length = abs(length)
return truncate_words(value, length, add_ellipsis)
}}}
Please feel free to commit this (diffs at end) if you feel that having
words truncated without ellipses is a use case that other developers
may have also. However, I do hope instead that we can address the
bigger problem here which is this:
Filters are currently artificially constrained to have a single
argument and this
Re: Multiple database support
Another couple weeks have slipped by and I continue to be crazy-busy. (But each week I'm busy for a different reason--so I continue to be foolishly optimistic that I'll soon get a week with some free time.) Anyway, I don't have time to read this thread through with the care it deserves, but I thought I shouldn't let that stop me from finally writing a description of the API I proposed at the PyCon sprint. Each app would have a databases.py file that contains classes used to define databases connections (in the same manner as classes are used to define models). Here's an example: from django.db import connections class LegacyDatabase(connections.DatabaseConnection): engine = 'sqlite3' name = '/foo/bar/legacy_db.sqlite3' (And the other DATABASE_* settings (from settings.py) could certainly be defined as attributes of a DatabaseConnection class.) JUST FOR TESTING, I propose we allow a database connection to be specified in a model with a Meta attribute, like this: from django.db import models from legacy.databases import LegacyDatabase class LegacyStuff(models.Model): ... class Meta: db_connection = LegacyDatabase Jacob expressed his extreme distaste for this at PyCon--for good reason. (We don't want to encourage coupling models to databases.) But just so we can get a working patch and start testing, I propose we go with this for now. Adrian suggested we allow the specification of database connections per-app using the new app() function being proposed for settings.py. I haven't seen a description of this since PyCon, but I think it would look something like: app(name='legacy', db_connection='LegacyDatabase') (I'm sure I'm leaving several important arguments out of this example.) Perhaps one could implement sharding by defining multiple DatabaseConnection classes in a databases.py file (we could support these files at the project level in addition to the app level) and putting them in a list. Then one could write a function to return the appropriate database to use and specify that callable in the argument to the app function (or perhaps as an argument to the url function in urls.py). I haven't given any thought to replication. Perhaps someone who needs this could think about whether this proposal could somehow make supporting replication easier (or if it might get in the way), or if it's simply orthogonal to this. -- Daryl On Wed, May 28, 2008 at 12:25 AM, koenb <[EMAIL PROTECTED]> wrote: > > On 22 mei, 18:28, "Ben Ford" <[EMAIL PROTECTED]> wrote: >> Hi all, >> >> I've now re-applied Daryls patch (which was against qsrf) to a clone of >> django trunk in a mercurial repo. It's available >> athttp://hg.woe-beti.deandthere's a trac set up for it >> athttp://trac.woe-beti.de. Feel free to make use of both of these. Although >> I've disabled to ability to create tickets perhaps the wiki might be a good >> place to discuss the API? Anyone can clone from the hg repo, give me a shout >> if you would like push access and I'll sort it out. >> >> Cheers, >> Ben >> >> -- >> Regards, >> Ben Ford >> [EMAIL PROTECTED] >> +447792598685 > > I have been adding some code to Ben's mercurial repo on [http://hg.woe- > beti.de], see also [http://trac.woe-beti.de]. > > What has been realised (more or less): > - connection and model registration > - validation that related objects use the same connection > - database_engine specific SQL generation (needs more checking) > - some management commands accept connection parameter, others can > generate output for multiple connections > - syncdb can sync different connections > - transaction management over connections > - some tests (needs a lot more work) > > This means point 3 of the discussion at [http://trac.woe-beti.de/wiki/ > Discuss] is somewhat working, but definitely needs a lot more testing. > > I do need some help with creating tests for all this though. > I have not figured out yet how to create tests that check that the > right SQL is being generated for the backend used. (Nor how to test > the right database was touched by an action, this is quite obvious > manually, but I do not know how to automate this.) > > I put some ideas on using multiple databases for copying (backup or > migration) of objects (point 4 of the discussion note) in [http:// > trac.woe-beti.de/wiki/APIModelDuplication]. > > Please comment, add, shoot etc. Any help will be much appreciated. > > Koen > > > --~--~-~--~~~---~--~~ 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: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)
Hi Russell, Cool, thanks -- will post it as a ticket now. And apologies for the messed up syntax in the previous post -- will clean it up for the ticket. Aral On Jun 4, 12:28 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Wed, Jun 4, 2008 at 6:20 PM, Aral Balkan <[EMAIL PROTECTED]> wrote: > > > Please feel free to commit this (diffs at end) if you feel that having > > words truncated without ellipses is a use case that other developers > > may have also. However, I do hope instead that we can address the > > bigger problem here which is this: --~--~-~--~~~---~--~~ 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: syncdb issues
On Wed, Jun 4, 2008 at 8:26 PM, greg.newman <[EMAIL PROTECTED]> wrote: > > I'm trying to syncdb in a project and am getting the following error > running python 2.5.1 with django 0.96. > Anyone have a clue why? Need more info, let me know. Django-developers is for discussing the development of Django itself, not for general usage questions. Cross posting between Django-users and Django-developers is also discouraged. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
syncdb issues
I'm trying to syncdb in a project and am getting the following error
running python 2.5.1 with django 0.96.
Anyone have a clue why? Need more info, let me know.
greg-3:examples greg$ python manage.py syncdb
Traceback (most recent call last):
File "manage.py", line 16, in
execute_manager(settings)
File "/Library/Python/2.5/site-packages/django/core/management.py",
line 1657, in execute_manager
project_directory = setup_environ(settings_mod)
File "/Library/Python/2.5/site-packages/django/core/management.py",
line 1649, in setup_environ
project_module = __import__(project_name, {}, {}, [''])
ValueError: Empty module name
--~--~-~--~~~---~--~~
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: Lost stdout and stderr on fcgi with Django
> Can you suggest any documentation I should read that describes how > FastCGI handles PIPES and file channels. The FastCGI spec. should be fine. > I thought something like that was happening but, if that was the case > wouldn't the output to stderr and stdout end up in the rendered pages > (like they do for php pages). I have poked and prodded but as near as > I can tell normal stdout and stderr are just being dumped to /dev/null > and the rendering seems to be going its own direction. Well, you rarely want your errors just sent out. It ruins a lot of things, like image formats and such. You have to change Python's sys.stderr to something "better", perhaps a log file or something. It needs a real FD. Ludvig "toxik" Ericson [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 -~--~~~~--~~--~--~---
Re: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)
On Wed, Jun 4, 2008 at 6:20 PM, Aral Balkan <[EMAIL PROTECTED]> wrote: > > Please feel free to commit this (diffs at end) if you feel that having > words truncated without ellipses is a use case that other developers > may have also. However, I do hope instead that we can address the > bigger problem here which is this: Hi Aral, Thanks for the contribution, but this should be submitted as a ticket, rather than posted to the mailing list. Tickets act as a permanent archive of suggestions that have been made; messages on a mailing list tend to get lost after a while. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
