ModelChoiceField's clean() uses default manager instead of query set
The clean() methods in both ModelChoiceField and ModelMultipleChoiceField use a block similar to the following in order to validate the selected choice: try: value = self.queryset.model._default_manager.get(pk=value) except self.queryset.model.DoesNotExist: raise ValidationError(ugettext(u'Select a valid choice. That choice is not one of the available choices.')) Is there any reason that shouldn't simply be self.queryset.get(pk=value) ? I came across this in a project when I was trying to work out why it was allowing choices that I had explicitly filtered out of the queryset - and of course this explains it. Is there a reason that the default manager should be used instead of just the original queryset? --~--~-~--~~~---~--~~ 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: testing Django against many Pythons and databases
On Mon, 2007-08-06 at 22:10 -0500, Gary Wilson wrote: > I know there are various setups people have for doing this, like Jacob's > snippet: > > http://www.djangosnippets.org/snippets/106/ > > but I was wondering what other developers' thoughts would be on adding > something like this to Django proper. I'm just thinking that Django > should be able to test itself completely without any outside help. > > This sort of thing would also be useful in case we ever wanted to do > some automated gate keeping of the checkins. Probably not a good idea. It's not entirely trivial to get everything set up to do this sort of all-in-one testing, so it has very limited utility to the broader population. If you want to do it for automatic post-commit checking, it's a buildbot or putting the stuff in the post-commit script. Usually you're going to be running against one version and one database wrapper at a time anyway (if there's any chance of something failing), because otherwise any failures will really stack up. If you think everything is going to pass and want to run against the lot, it's a two line shell script, more or less (loop over PATH, python binary names and settings file names). I don't see it as solving the hard bit of any problem -- getting a setup that can support all six current database backends and three Python versions is 98% of the work required. Actually running the tests is then trivial. So -1 from me. Extra stuff to maintain (otherwise, I'd be -0) that isn't going to add a lot of value to most setups or make anything much easier than it already is. Cheers, Malcolm -- Everything is _not_ based on faith... take my word for it. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: possible deficiency in newform BooleanField?
On Aug 7, 2:28 pm, Gary Wilson <[EMAIL PROTECTED]> wrote: > I believe SmileyChris meant that a ticket should be opened about > updating the documentation. Correct > As mentioned in the comments of the ticket you mentioned above, there > are times when you do want to ensure the check box was checked > (required=True). When you do not want to force the user to check the > box, then you use required=False. I wouldn't say it's a hoop to jump > through, but rather just a configuration for the way you want your check > box to work. Actually, I think that it *is* a hoop to jump through - one created due to an issue with the CheckboxInput widget. But let's not discuss it here since I already started a new discussion thread: http://groups.google.com/group/django-developers/browse_thread/thread/6a30bedc9fc5c07d/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
testing Django against many Pythons and databases
I know there are various setups people have for doing this, like Jacob's snippet: http://www.djangosnippets.org/snippets/106/ but I was wondering what other developers' thoughts would be on adding something like this to Django proper. I'm just thinking that Django should be able to test itself completely without any outside help. This sort of thing would also be useful in case we ever wanted to do some automated gate keeping of the checkins. Gary --~--~-~--~~~---~--~~ 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: clean_* methods should be passed the value
SmileyChris wrote: > I know this would be backwards incompatible, but why on earth do our > newform clean_[fieldname] methods need to get the value out of the > self.cleaned_data dict. It just seems so un-DRY. This irritates me too. I'm +1 for passing the value, as noted by my patch attached to http://code.djangoproject.com/ticket/3896 some time ago. Gary --~--~-~--~~~---~--~~ 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: possible deficiency in newform BooleanField?
Ash wrote: > What would be the point in opening a ticket when this clearly broken > behavior gets marked as 'wontfix'? > > http://code.djangoproject.com/ticket/4981 I believe SmileyChris meant that a ticket should be opened about updating the documentation. > The documents for Django newforms state that: > > BooleanField > > * Default widget: CheckboxInput > * Empty value: None > * Normalizes to: A Python True or False value. > * Validates nothing (i.e., it never raises a ValidationError). > > > Note the last line. But when you actually go and use the field and > don't check it, it DOES raise a validation error, saying that "This > field is required." > > It is silly to say here that all boolean fields must be made > 'required=False' in order to work. That's not in the docs, and it's a > silly hoop to ask developers to jump through just to be able to have a > useful checkbox field. The field itself should be smart enough to know > that unchecked == False. Not that unchecked == missing. The documented > normalizing to either True or False is not happening at all. As mentioned in the comments of the ticket you mentioned above, there are times when you do want to ensure the check box was checked (required=True). When you do not want to force the user to check the box, then you use required=False. I wouldn't say it's a hoop to jump through, but rather just a configuration for the way you want your check box to work. Gary --~--~-~--~~~---~--~~ 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: clean_* methods should be passed the value
On Aug 7, 6:45 am, SmileyChris <[EMAIL PROTECTED]> wrote: > I know this would be backwards incompatible, but why on earth do our > newform clean_[fieldname] methods need to get the value out of the > self.cleaned_data dict. It just seems so un-DRY. > > If there is an edge case where you need to look at the dict, you still > could. But the normal case is that you are doing further validation or > cleaning to just the value of that Field. I always thought this was a bit clunky too. Most of my clean_* methods end up having: value = self.cleaned_data['fieldname'] ... return value I guess it's only one extra line, but it just feels a bit ugly. --~--~-~--~~~---~--~~ 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: Simple improvement suggestion for django.contrib.syndication.feeds
On 8/6/07, jorjun <[EMAIL PROTECTED]> wrote: > > I have never contributed a Django patch. I am a newbie with respect to > SVN and couldn't get SVN DIFF command to produce the required output. > Please excuse pasting code changes in here. Even if you can't generate an SVN diff, it would be better to post this in a ticket; posting it to the list means it is more likely to get lost in the traffic. 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 -~--~~~~--~~--~--~---
clean_* methods should be passed the value
I know this would be backwards incompatible, but why on earth do our newform clean_[fieldname] methods need to get the value out of the self.cleaned_data dict. It just seems so un-DRY. If there is an edge case where you need to look at the dict, you still could. But the normal case is that you are doing further validation or cleaning to just the value of that Field. Am I missing something obvious? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Solution to problems with newforms BooleanField
The main problem people have with BooleanField is that it raises a ValidationError if its checkbox widget is left unchecked. here is a problem, but it's not with BooleanField - *it's with the CheckboxInput (widget)*. CheckboxInput should only be able to return a value of True or False. That's it. If you want more than that, you should be using some other widget. (I just created ticket http://code.djangoproject.com/ticket/5104) The normal argument against changing BooleanField validation is that you may want an "I accept" checkbox. Really, you should be doing your own checking in clean_[field] to make sure it's not False. --~--~-~--~~~---~--~~ 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: ANN: Alpha release of new MS SQL Server backend
Thanks for the info. I test it and tommorrow in the next 2 days do another release... --~--~-~--~~~---~--~~ 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: How much test case must print runtest?
Nope. I enable the verbosity to 2 and only the webdesing test are running... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
About Changeset [5819]
First: Nice, that a working FileField got merged! (see: http://code.djangoproject.com/changeset/5819) After browsing the source to update my own patches I found that FileField.save_form_data() joins the filename and self.upload_to (see http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py?rev=5819#L785). Why is this done? If I read the code right self.upload_to gets stripped later in FileField.get_filename() and is added in File.get_directory_name(), again. Greetings, David Danier --~--~-~--~~~---~--~~ 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: How much test case must print runtest?
On 8/6/07, mamcx <[EMAIL PROTECTED]> wrote: > I use your config and get the same results :( Maybe you still have test.pyc in your folder? (c) -- Carlo C8E Miron PYC Troubles Solution Architect(tm) --~--~-~--~~~---~--~~ 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: ANN: Alpha release of new MS SQL Server backend
hey, sorry, forgot one thing: in django/db/models/fields 222 # mssql can not handle more than two 99-s 223 return ['%s-01-01 00:00:00' % value, '%s-12-31 23:59:59.99' % value] On Aug 3, 6:34 pm, mamcx <[EMAIL PROTECTED]> wrote: > Excelent. Please send me your patch so I take a look at it. > > I finish today a implementation of LIMIT so I'm interested in how you > solve it. --~--~-~--~~~---~--~~ 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: ANN: Alpha release of new MS SQL Server backend
mamcx, I sent you my mods. Jeremy, I tested the admin + pymssql backend again without my modification (i.e. changing object_id's type), and now seems to be working just fine. do not really know what was causing the issue before though. anyway, thanks for the information. Peter On Aug 4, 9:21 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > On 8/3/07, pk11 <[EMAIL PROTECTED]> wrote: > > > the issue with object_id is that mssql can not insert an integer PK > > into a TEXT field. > > I guess I'm confused. Admin LogEntryManager forces object_id to a > string before saving. Do you see somewhere that's directly filling > LogEntry.object_id with an integer? --~--~-~--~~~---~--~~ 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: How much test case must print runtest?
I use your config and get the same results :( --~--~-~--~~~---~--~~ 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: How much test case must print runtest?
On 8/6/07, mamcx <[EMAIL PROTECTED]> wrote: > > Nope... > > I change the name and get the same numbers. > > The settings must have something special? what is the bare minimun? This is all that I'm using: DATABASE_ENGINE = 'sqlite3' DATABASE_NAME = 'django_test.s3db' SITE_ID = 1 ROOT_URLCONF = '' -Ian --~--~-~--~~~---~--~~ 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: How much test case must print runtest?
Nope... I change the name and get the same numbers. The settings must have something special? what is the bare minimun? --~--~-~--~~~---~--~~ 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: How much test case must print runtest?
On Mon, Aug 06, 2007 at 10:34:32AM -0600, Ian Kelly wrote: > > On 8/6/07, mamcx <[EMAIL PROTECTED]> wrote: > > > > Ok, I do CD to the folder where test is, then run: > > > > runtests.py --settings test > > > > test.py is a settings file with the new backend and db config. You might have a name collision with your settings file and another critical module somewhere. Perhaps you should rename your settings file to testmssql.py? -Forest -- Forest Bond http://www.alittletooquiet.net signature.asc Description: Digital signature
Re[4]: Case-insensitive URLS (was: usability issues)
Tom, Thank you for clarification. Now that makes a lot of sense for me. ~ Alex You wrote 6 ??? 2007 ?., 20:28:20: > On 8/6/07, Alex Nikolaenkov <[EMAIL PROTECTED]> wrote: >> > If a core dev closes a ticket with a "wontfix", you shouldn't re-open >> > the ticket unless you've made a compelling case on django-dev and >> > gotten the core devs to change their minds. "Wontfix" essentially >> > means that a design decision has been made against the proposal, and >> > re-opening the ticket isn't going to change that. >> >> How can I find out that the one closed is the core dev? ^_^ I thought that >> ticket was closed by a few volunteers reviewing them first (volunteers >> are mentioned near the bug-reviewing-process-scheme). >> Here is much of django process issues. Thanks for clarification. BTW >> where can I find list of core developers? > Well, a volunteer / triager might also close it as "wontfix" if it's > been made clear in the past by a core dev that such a decision has > been made, and in these cases the same thing applies. (They should > hopefully point this out in the close comment.) The core devs are the > people listed as "primary authors" here: > http://code.djangoproject.com/browser/django/trunk/AUTHORS >> > Yes, whenever a ticket is closed, it should have a reason attached; if >> > one is missing, feel free to comment on the ticket asking for a reason >> > -- but *without* re-opening the ticket. >> >> BTW I can't get why reopening tickets is treated as the major issue. >> Just one more ticket. Just a message. Just a discussion. And so on. If >> I request for comments without re-opening, time consumption is much the >> same. So what's the difference? > Developers use the "open" status of a ticket to track if it needs to > be addressed; that's why the "open" status of a ticket matters. If > something has been closed for a valid reason, there needs to be a > *good* reason to re-open it; developer time is scarce and tickets are > plenty. It has nothing to do with stifling discussion, and everything > to do with making efficient use of limited time. You're more than > welcome to raise a discussion here regarding the closing of a ticket > when you disagree with the reasoning; you're also welcome to post a > comment on the ticket while leaving it closed. If you change minds > regarding the issue, the ticket will get re-opened. -- Best regards, Alex mailto:[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: How much test case must print runtest?
On 8/6/07, mamcx <[EMAIL PROTECTED]> wrote: > > Ok, I do CD to the folder where test is, then run: > > runtests.py --settings test > > test.py is a settings file with the new backend and db config. > > I do a little debugging and I think find a bug. > > The test are executed on: > > failures = run_tests(test_labels, verbosity=verbosity, > extra_tests=extra_tests) > > but test_labels always is empty. So I add this code: > > for model_dir, model_name in get_test_models(): > test_labels.append(load_app(model_label)) > > and now get 84 tests executed. > > However I think is weird that the code not work at all... maybe is > because is executed under windows This is the output that I'm getting (rev5821, sqlite3 backend, Windows XP): C:\DOCUME~1\ikelly\projects\django\tests>python runtests.py --settings projects.testsqlite -- Ran 154 tests in 38.244s OK -Ian --~--~-~--~~~---~--~~ 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: possible deficiency in newform BooleanField?
What would be the point in opening a ticket when this clearly broken behavior gets marked as 'wontfix'? http://code.djangoproject.com/ticket/4981 The documents for Django newforms state that: BooleanField * Default widget: CheckboxInput * Empty value: None * Normalizes to: A Python True or False value. * Validates nothing (i.e., it never raises a ValidationError). Note the last line. But when you actually go and use the field and don't check it, it DOES raise a validation error, saying that "This field is required." It is silly to say here that all boolean fields must be made 'required=False' in order to work. That's not in the docs, and it's a silly hoop to ask developers to jump through just to be able to have a useful checkbox field. The field itself should be smart enough to know that unchecked == False. Not that unchecked == missing. The documented normalizing to either True or False is not happening at all. On Jun 17, 3:39 pm, SmileyChris <[EMAIL PROTECTED]> wrote: > On Jun 18, 10:23 am, Mike H <[EMAIL PROTECTED]> wrote: > > > Perhaps the example in the > > docs needs updating to show required=False in the cc_myself field? > > Perhaps you should make a ticket. > /me cracks the ticket manager whip. ;) --~--~-~--~~~---~--~~ 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: Re[2]: Case-insensitive URLS (was: usability issues)
On 8/6/07, Alex Nikolaenkov <[EMAIL PROTECTED]> wrote: > > If a core dev closes a ticket with a "wontfix", you shouldn't re-open > > the ticket unless you've made a compelling case on django-dev and > > gotten the core devs to change their minds. "Wontfix" essentially > > means that a design decision has been made against the proposal, and > > re-opening the ticket isn't going to change that. > > How can I find out that the one closed is the core dev? ^_^ I thought that > ticket was closed by a few volunteers reviewing them first (volunteers > are mentioned near the bug-reviewing-process-scheme). > Here is much of django process issues. Thanks for clarification. BTW > where can I find list of core developers? Well, a volunteer / triager might also close it as "wontfix" if it's been made clear in the past by a core dev that such a decision has been made, and in these cases the same thing applies. (They should hopefully point this out in the close comment.) The core devs are the people listed as "primary authors" here: http://code.djangoproject.com/browser/django/trunk/AUTHORS > > Yes, whenever a ticket is closed, it should have a reason attached; if > > one is missing, feel free to comment on the ticket asking for a reason > > -- but *without* re-opening the ticket. > > BTW I can't get why reopening tickets is treated as the major issue. > Just one more ticket. Just a message. Just a discussion. And so on. If > I request for comments without re-opening, time consumption is much the > same. So what's the difference? Developers use the "open" status of a ticket to track if it needs to be addressed; that's why the "open" status of a ticket matters. If something has been closed for a valid reason, there needs to be a *good* reason to re-open it; developer time is scarce and tickets are plenty. It has nothing to do with stifling discussion, and everything to do with making efficient use of limited time. You're more than welcome to raise a discussion here regarding the closing of a ticket when you disagree with the reasoning; you're also welcome to post a comment on the ticket while leaving it closed. If you change minds regarding the issue, the ticket will get re-opened. --~--~-~--~~~---~--~~ 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: How much test case must print runtest?
Ok, I do CD to the folder where test is, then run: runtests.py --settings test test.py is a settings file with the new backend and db config. I do a little debugging and I think find a bug. The test are executed on: failures = run_tests(test_labels, verbosity=verbosity, extra_tests=extra_tests) but test_labels always is empty. So I add this code: for model_dir, model_name in get_test_models(): test_labels.append(load_app(model_label)) and now get 84 tests executed. However I think is weird that the code not work at all... maybe is because is executed under windows --~--~-~--~~~---~--~~ 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[2]: Case-insensitive URLS (was: usability issues)
> On 8/6/07, Alex Nikolaenkov <[EMAIL PROTECTED]> wrote: >> >> I never heard that tickets should not be reopened if you disagree. If >> the bug is still reproducible it should be reopened. If its >> resolution is changed to "won't fix", one should point why. And >> not just - "Oh, it is good enough now". The only one who CLOSES the >> ticket is the opener. So it's also very impolite to CLOSE TICKETS FOR >> SOMEONE. Correct me if I'm wrong. > You're (partially) wrong. ^_^ > If a core dev closes a ticket with a "wontfix", you shouldn't re-open > the ticket unless you've made a compelling case on django-dev and > gotten the core devs to change their minds. "Wontfix" essentially > means that a design decision has been made against the proposal, and > re-opening the ticket isn't going to change that. How can I find out that the one closed is the core dev? ^_^ I thought that ticket was closed by a few volunteers reviewing them first (volunteers are mentioned near the bug-reviewing-process-scheme). Here is much of django process issues. Thanks for clarification. BTW where can I find list of core developers? > Yes, whenever a ticket is closed, it should have a reason attached; if > one is missing, feel free to comment on the ticket asking for a reason > -- but *without* re-opening the ticket. BTW I can't get why reopening tickets is treated as the major issue. Just one more ticket. Just a message. Just a discussion. And so on. If I request for comments without re-opening, time consumption is much the same. So what's the difference? -- Best regards, Alex mailto:[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[2]: Case-insensitive URLS (was: usability issues)
You wrote 6 ??? 2007 ?., 16:38:25: > On 8/6/07, Alex Nikolaenkov <[EMAIL PROTECTED]> wrote: >> BTW, Can we attach configurable plug-ins to the built-in webserver? >> (* I'm interested in possibility. Can code "case insensitive urls >> plug-in" by myself. *) > You're looking for "middleware": > http://www.djangoproject.com/documentation/middleware/ or > http://www.djangobook.com/en/beta/chapter16/. > Jacob Thank you very much. I haven't read the whole djangobook yet. I've got: here is not the right place to ask such questions. But they do arise in my head while typing. Just skip if they bother. I WILL answer them by myself. Still very green in python, but will learn rapidly. You'll see. I promise: no questions till I read the whole djangobook. I'll write'em down and try to answer by myself & google after reading. If no answer is found, I'll post them here. ~ Alex mailto:[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 -~--~~~~--~~--~--~---
ticket ping
Hi, could one of the core devs please take a look at ticket #4827? This is a severe Oracle-backend bug (syncdb failure) with a simple patch that's been around since the merge of the Unicode branch. It's been reported at least four times that I've seen, so I think that users must be encountering this on a fairly regular basis. Thanks, Ian --~--~-~--~~~---~--~~ 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: Case-insensitive URLS (was: usability issues)
On 8/6/07, Alex Nikolaenkov <[EMAIL PROTECTED]> wrote: > > I never heard that tickets should not be reopened if you disagree. If > the bug is still reproducible it should be reopened. If its > resolution is changed to "won't fix", one should point why. And > not just - "Oh, it is good enough now". The only one who CLOSES the > ticket is the opener. So it's also very impolite to CLOSE TICKETS FOR > SOMEONE. Correct me if I'm wrong. You're (partially) wrong. ^_^ If a core dev closes a ticket with a "wontfix", you shouldn't re-open the ticket unless you've made a compelling case on django-dev and gotten the core devs to change their minds. "Wontfix" essentially means that a design decision has been made against the proposal, and re-opening the ticket isn't going to change that. If you can still reproduce a bug after it has been closed as "fixed", yes, you should re-open the relevant ticket while stating as much. If a ticket has been closed as "invalid", you should only re-open it if you're certain the issue really is with Django rather than something else. If in doubt, ask django-users for help regarding such an issue. Yes, whenever a ticket is closed, it should have a reason attached; if one is missing, feel free to comment on the ticket asking for a reason -- but *without* re-opening the ticket. --~--~-~--~~~---~--~~ 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: How to validate a model as a whole?
Any suggestions for what to do in the meantime? :-\ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Simple improvement suggestion for django.contrib.syndication.feeds
6c6,7
< from django.conf import settings
---
> from django.conf import settings
> from django.template import RequestContext
120c121
< title = title_tmp.render(Context({'obj': item,
'site': current_site})),
---
> title = title_tmp.render(RequestContext(self.request, {'obj':
> item, 'site': current_site})),
122c123
< description = description_tmp.render(Context({'obj':
item, 'site': current_site})),
---
> description =
> description_tmp.render(RequestContext(self.request, {'obj': item, 'site':
> current_site})),
Having an easy time implementing RSS here, thanks to syndication.feeds
but found myself wanting extra context information in the description
and title templates...
If the above changes were made, then add extra context could be added
using the the existing context_processor mechanism. I can't perceive a
down-side myself - but would be interested in observations from
others, of course.
I have never contributed a Django patch. I am a newbie with respect to
SVN and couldn't get SVN DIFF command to produce the required output.
Please excuse pasting code changes in here.
--~--~-~--~~~---~--~~
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: schema evolution (new and improved)
Russell Keith-Magee wrote: > Your approach is predicated on the assumption that migrating > v1->v2->v3 is equivalent to v1->v3. This is true if you only look at > renaming, deleting or adding the fields themselves. so i think i have a cross-over solution. :) what it boils down to is there are four basic categories of developers: 1. users who trust introspection and never want to touch/see SQL 2. users who mostly trust introspection but want the option of auto-applied upgrades for specific situations (Wash) 3. users who use introspection-generated SQL, but don't trust it (they want it generated at development and stored for use in production) 4. users who hate introspection and just want auto-application of their own scripts who wish to perform different combinations of the two basic subtasks of schema evolution: 1. generation of SQL via magical introspection 2. storage and auto-application of upgrade SQL the first i've detailed before, so i won't cover here. it works the same way. the second works through auto-identification of known schema types, and the application of pre-rendered scripts. now this is very similar what other code out there does (for instance mikeh's quite capable dbmigration project [http://www.aswmc.com/dbmigration/]), but i feel in a simultaneously simpler and more flexible way. specifically, the following i consider key goals: * there is no need for schema identification metadata to be stored in the database itself * you should be able to swap between introspection and custom scripts freely within the same project, using as much or at little of each as you want (with little or no transition costs) * full migration graphs should be supported, not just linear steppings * it should be butt easy to use (because if it's not simpler than keeping your own text file, noone is going to use it) note: all this is covered in greater depth here: http://code.djangoproject.com/wiki/SchemaEvolutionDocumentation for the developers work, all they have to do is define a new module named 'schema_evolution' in their app directory, next to 'models'. this contains two data structures: * a list of known schema fingerprints * a dict mapping (from_fprint,to_fprint) pairs to scripts (lists of sql statements and/or python function calls, to be run in order...think pre_script/sql/post_script) the fingerprints act as both version numbers and ids, and are automatically generated. (either by you, running './manage sqlfingerprint my_app' or by sqlevolve or syncdb when they're looking for what scripts are available and comparing them to the existing schema) when schema evolution is applied, specified scripts ALWAYS take priority over introspection generated sql...so if you never want to see an aka field or generated sql, you never have to. different users i imagine will use it in different ways, but i imagine that most people will use introspection the majority of the time, ignoring fingerprints until they hit a bump that introspection can't handle. they'll simply code that one transition and continue on their way storing only that one tricky transition. a different subset of developers i imagine will always use the stored scripts during deployment, but will use introspection to generate the majority of them. but they will store all transitions, having a full version history of every state of their db stored in svn. anyway, an example of the evolution file is available in the documentation. let me know what you think. :) oh yeah, it's mysql only at this pointi want to get some feedback on the design before i write the others. thanks! derek p.s. mike i like your stuff but i feel that the whole-hog approach requiring developers to either start their db with your scripts or face a complicated setup is overly burdensome. plus users are lazyi don't want their hand-written scripts to be the only check for whether or not it's safe to apply a particular script. but maybe there are parts where we can merge or projects together? pm me. --~--~-~--~~~---~--~~ 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: test coverage [was: web typography support]
On 8/6/07, Emanuele Pucciarelli <[EMAIL PROTECTED]> wrote: > There's Ned Batchelder's coverage.py: http://nedbatchelder.com/code/ > modules/coverage.html . Haven't tried it myself, but I have to > suppose that it's Django-friendly. :) A while back I started experimenting with coverage using figleaf (Titus Brown's next-gen spinoff of coverage.py). I particularly liked figleaf's HTML output; far easier to read than a whole honking mess of console text. I keep meaning to dust it off and finish it up, but haven't had the chance. Coverage support would be *great* to have in Django-proper, though, so if anyone wants to experiment with figleaf, coverage, or anything else I'd *love* to review some patches. Jacob --~--~-~--~~~---~--~~ 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: test coverage [was: web typography support]
On 8/6/07, Emanuele Pucciarelli <[EMAIL PROTECTED]> wrote: > There's Ned Batchelder's coverage.py: http://nedbatchelder.com/code/ > modules/coverage.html . Haven't tried it myself, but I have to > suppose that it's Django-friendly. :) http://siddhi.blogspot.com/2007/04/code-coverage-for-your-django-code.html http://eddymulyono.livejournal.com/62101.html Brett --~--~-~--~~~---~--~~ 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: Case-insensitive URLS (was: usability issues)
Hi, On 8/6/07, Alex Nikolaenkov <[EMAIL PROTECTED]> wrote: > > Right, so moving on to your real question: > >>Here is an example of case-insensitive urls. They rock: > >>http://www.askeri.ru/PUBLISH/ > >>http://www.askeri.ru/publish/ > > > They do indeed rock. Luckily, supporting them is super-easy:: > > (r'(?P[\w]+)/$', my_view) > > def my_view(request, slug): > > o = MyObject.objects.get(slug__iexact=slug) > > Bingo; case-insensitive URLs! Rock on. > That's understood. But this code smells bad. Dont you think so? > F.e. most even do not know what '(?: )' means. Furthermore view is not > the right place to parse urls. View is a formatting object in my > viewpoint. Just like the XSLT template. Please just learn django. Thank you. --~--~-~--~~~---~--~~ 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: Case-insensitive URLS (was: usability issues)
On 8/6/07, Alex Nikolaenkov <[EMAIL PROTECTED]> wrote: > BTW, Can we attach configurable plug-ins to the built-in webserver? > (* I'm interested in possibility. Can code "case insensitive urls > plug-in" by myself. *) You're looking for "middleware": http://www.djangoproject.com/documentation/middleware/ or http://www.djangobook.com/en/beta/chapter16/. Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
test coverage [was: web typography support]
Il giorno 06/ago/07, alle ore 08:10, Alex Nikolaenkov ha scritto: > IMO TDD is a very good practice. So unit-tests for applications to be > included into the standard django package are the must. Are there > tools for python showing "unit test coverage" for the module > (Something like Jester for Java)? There's Ned Batchelder's coverage.py: http://nedbatchelder.com/code/ modules/coverage.html . Haven't tried it myself, but I have to suppose that it's Django-friendly. :) Regards, -- Emanuele --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Custom Expires header for django.views.static.serve
Hi.
I thought I share some code with you.
All began with my laziness to set up a Apache or Lighttp server to
serve up my static files for django. So I used djangos own
django.views.static.serve to serve my files. Only problem was that I
was unable to set Expires header for files served that way, so I made
some modifications to django. Here's the result.
Sample url.py file:
from django.conf.urls.defaults import *
from django.views.static import expires
urlpatterns = patterns('',
(r'^media/(.*)$', 'django.views.static.serve', {
'document_root': 'media',
'show_indexes': False,
'expires': expires((60 * 60, # default expiry time
(r'\.jpg$', 60 * 60 * 7),
(r'\.css$', 60 * 2),
(r'\.js$', False), # uses default
))
}
),
)
and a patch to django:
Index: django/views/static.py
===
--- django/views/static.py (revision 5818)
+++ django/views/static.py (working copy)
@@ -9,7 +9,7 @@
import stat
import urllib
-def serve(request, path, document_root=None, show_indexes=False):
+def serve(request, path, document_root=None, show_indexes=False,
expires=False):
"""
Serve static files below a given point in the directory
structure.
@@ -55,6 +55,14 @@
contents = open(fullpath, 'rb').read()
response = HttpResponse(contents, mimetype=mimetype)
response["Last-Modified"] =
rfc822.formatdate(statobj[stat.ST_MTIME])
+if expires:
+from time import time
+now = time()
+for (path_re, path_expire, seconds) in expires:
+if path_re.search(path):
+response["Expires"] = rfc822.formatdate(now +
seconds)
+break
+
return response
DEFAULT_DIRECTORY_INDEX_TEMPLATE = """
@@ -123,3 +131,22 @@
except (AttributeError, ValueError):
return True
return False
+
+def expires(expires_tuple):
+"""
+Precompiles regexes from expires list.
+
+expires_tuple
+ List of tuples containing path regex and number of seconds to
add to current timestamp.
+ First item is a default seconds to add if path seconds is 0 or
False.
+
+returns a new list with precompiled regexes
+"""
+expires_list = []
+default_seconds = expires_tuple[0]
+for (path_re, seconds) in expires_tuple[1:]:
+if not seconds:
+seconds = default_seconds
+expires_list.append((re.compile(path_re), path_re, seconds))
+return expires_list
+
--
Tõnis Kevvai
--~--~-~--~~~---~--~~
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: GSoC 2007 Status Update VI: Django REST interface
2007/8/5, Andreas Stuhlmüller <[EMAIL PROTECTED]>: > > I am currently reading "RESTful Web Services" by Leonard Richardson > and Sam Ruby. See [3] for a summary of the main points from the > chapter on best practices for REST-oriented architectures with short > notes on where the REST interface still needs improvement. Really interesting summary, thanks for this work. > > If you feel that there are important issues I am missing, please write > me or just open a ticket [4]. Here are some random thoughts: * What about additional pages like: create form, update form, delete confirmation and so on? I've just noticed the get_create_form at the end of the TemplateResponder but how can I redirect to this function? (I haven't seen how to do this in url generation.) * How can I deal with custom forms for a resource? * Is it possible to specify the format at the end of an url or will it break the parsing? And last but not least, what is the current stability? I need to use this kind of library now and even if I develop my own last week which fits my needs, I hope this one will replace it soon because I don't want to break all my code once this project is merged to the trunk. Regards, David --~--~-~--~~~---~--~~ 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[2]: web typography support
Hi James! > You might want to have a look at this before starting your own project: > http://code.google.com/p/typogrify/ Thank you for your link. I saw. It implements only a small piece of typography. There are a lot more features to do, including * comprehensive documentation with examples * unit tests * Multi-language support * Correct white-space handling. a lot more about typography itself. -- Best regards, Alex mailto:[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: GSoC 2007 Status Update IV: Django REST interface
2007/8/3, Andreas Stuhlmüller <[EMAIL PROTECTED]>: > > On 7/13/07, David Larlet <[EMAIL PROTECTED]> wrote: > > * About users, how can I handle django users' permissions? John > > Sutherland had already done some work on django-crudapi [1] and it > > could be interesting to allow this access control. > > Good question. I would subclass one of the authentication classes, > e.g. HttpBasicAuthentication, and add a has_perm() check dependent on > the request method to is_authenticated(). > > Currently, REST authentication is independent from Django's > authentication middleware. It might make sense to move most of the > code in HttpBasicAuthentication and HttpDigestAuthentication to > django.contrib.auth.backends and to let the middleware do most of the > work. > Sounds good to me. > > I'm not fond of CRUD names and I prefer to keep an information on > > the HTTP verb in the function name but it's maybe personal. > > I chose the CRUD names as they better describe what the methods > actually do, but if the consensus is that it is more important to > highlight the HTTP method, I will change this. Eventually, I'm not against CRUD names but maybe we could be consistent with rails ones? > Thanks for your comments! > Thanks for your answer :) Regards, David --~--~-~--~~~---~--~~ 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: web typography support
On 8/6/07, Alex Nikolaenkov <[EMAIL PROTECTED]> wrote: > Can you publish your plan concerning contributing applications? The first > thing I'll do in django & python will be typography support. You might want to have a look at this before starting your own project: http://code.google.com/p/typogrify/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
web typography support
ME: >> * What do you think about including Web Typography support as a >>built-in django feature? Jacob: > I think it's a great idea. We currently don't have a process by which > apps are added to contrib, and that's the only thing holding us back. > I'm working on proposing such a process, and once the development > community has had a chance to tell me where I got it wrong, typography > is one of the first things I'd like to propose for addition to > contrib. Web typography is a feature which will put Django 10 steps ahead many other CMS, most of which were written not for making high-valued super-fast web sites, but for the purpose of money by the bunch of people not understanding WHAT THE WEB REALLY IS. Can you publish your plan concerning contributing applications? The first thing I'll do in django & python will be typography support. From my point of view every application should be at least: * stable enough to be included into the Django package. The OK level of quality should be defined. IMO TDD is a very good practice. So unit-tests for applications to be included into the standard django package are the must. Are there tools for python showing "unit test coverage" for the module (Something like Jester for Java)? * Have bugtracker for user support * Comprehensive free documentation. * Compatible license Are commercial modules are allowed? I think this is a big yes-yes to include commercial modules support to django. Someone will be able to build business writing good applications for YOUR system ;) Eh... what do u think? -- Best regards, Alex mailto:[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: Case-insensitive URLS (was: usability issues)
Twas brillig at 09:49:49 06.08.2007 UTC+04 when Alex Nikolaenkov did gyre and gimble: AN> BTW, Can we attach configurable plug-ins to the built-in webserver? (* I'm AN> interested in possibility. Can code "case insensitive urls plug-in" by AN> myself. *) I already pointed out that Django middleware is the proper place for such things. Please read the documentation about middleware, and you'll see how easy it is to add such functionality as case-insensitive URLs (keeping in mind that case-insensitive URLs should not affect business logic - imagine you have API for application: it would be very disturbing to have case-insensitvie API). -- JID: [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 -~--~~~~--~~--~--~---
