Re: Preventing the leaking of sensitive information in error logs
Many thanks to all for the feedback. I've just posted a new patch, welcoming any further feedback: https://code.djangoproject.com/attachment/ticket/14614/14614.exception-reporter-filter.diff Regards, Julien -- 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: support for custom django-admin commands written as packages
Hi Marwan, On 06/05/2011 10:15 AM, Marwan Al-Sabbagh wrote: > Hello, > Currently one can create a custom command by implementing a Command > object in a python module such as > "polls/management/commands/closepoll.py". It would be great if Django > also supported these commands being implemented in a python package so > in this case Command would be found in > "polls/management/commands/closepoll/__init__.py". This would be > useful when a command contains a lot of logic or code and the > developer would like the ability to split up the logic into multiple > files to make the code base more manageable. I faced this issue > recently when I implemented a command that would be run as a cron job > to periodically import data into Django from a legacy system that had > some pretty hairy logic to deal with. >I've already made the changes to support the feature, it only > required a change to the function > django.core.management.find_commands() to look for packages as well as > modules in each commands directory. I thought I'd run it by > django-developers before creating the ticket on trac with the patch. > What do you guys think? I'm not a big fan of the way Django finds management commands. Searching directly on the filesystem makes Django apps with management commands incompatible with legitimate builtin Python features such as import hooks or zipfile imports. IMHO, regardless of what you think of those Python features, this makes Django somewhat less than "just Python." That said, I don't have a great alternative in mind at the moment, but I don't like the idea of taking the current bad system and extending it with even more complexity. Generally my approach to the problem you describe is to make the management command itself a minimal wrapper around the core code, implemented as functions and classes within appropriately-named submodules of the app itself, not within the myapp.management.commands.mycommand namespace. I almost always at some point want to reuse that code as library code, so I actually find it preferable if the bulk of the code lives outside the management.commands namespace, and is just imported and used by the management command. This can also encourage a separation of responsibilities that makes testing easier. Carl -- 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: [GSoC composite fields] Weekly check-in #1
All right, time for another check-in. This isn't a lengthy one -- unfortunately last Tuesday my laptop failed me, leaving me with no replacement, which means I have to wait for it to return from the service center to be fully up and running. In the meantime, I managed to borrow an old one a couple of days ago but it isn't set up yet; I'm working on that. At least I can keep my repo in sync with trunk at the moment... Anyway, I hope the next update will be a more productive one. Until then... Michal > [1] https://github.com/konk/django signature.asc Description: Digital signature
Re: Allow disabling choices in a
On Saturday, June 4, 2011 4:50:12 AM UTC+12, Jody McIntyre wrote: > > I can't think of a more concise way of clearly representing that 'bananas' > is disabled while still allowing it to have a label [...] > I'd say it would be more backwards compatible, and still reasonably concise to just have a separate attribute: disabled_choices = ('bananas',) -- 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/-/NlVzSVQwYnU5Z3dK. 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: Test optimizations (2-5x as fast)
On Jun 5, 2011, at 10:18 AM, Ned Batchelder wrote: > When I try this on a PostgreSQL database, I have problems relating to > violated uniqueness constraints, sometimes from tests themselves, sometimes > from setUpClass, sometimes from tearDownClass. In the latter two cases, it's > the sites table involved. Is this something others have dealt with, or am I > on my own? :) Do you perchance have anything getting inserted into tables other than the ones explicitly mentioned in your fixtures, perhaps by a post_save signal? The code I have up at the moment doesn't deal with that. A cheap way to make it work would be to truncate *all* tables on teardown_fixtures (slow, ick). I will be sure to give it a swing with Postgres; I hope to find time to work on the Django patch sometime this week. Erik -- 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: Test optimizations (2-5x as fast)
On Fri, May 13, 2011 at 11:57 PM, Erik Rose wrote: > tl;dr: I've written an alternative TestCase base class which makes > fixture-using tests much more I/O efficient on transactional DBs, and I'd > like to upstream it. > [...] > 1. Class-level fixture setup > [...] > 2. Fixture grouping > [...] Only wanted to point that optimization of database data fixture loading in tests is the topic of ticket [1]9449 in the Django bug tracker. The two contributors that participated in the discussion there so far took the fixture caching path, but I think the ticket can be considered associated with the general problem and so is open for other solution strategies. -- Ramiro Morales 1. https://code.djangoproject.com/ticket/9449 -- 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: Test optimizations (2-5x as fast)
On Sun, Jun 5, 2011 at 5:18 PM, Ned Batchelder wrote: > When I try this on a PostgreSQL database, I have problems relating to > violated uniqueness constraints, sometimes from tests themselves, sometimes > from setUpClass, sometimes from tearDownClass. In the latter two cases, > it's the sites table involved. Is this something others have dealt with, or > am I on my own? :) > > I tried adding a PostgreSQL "disable constraints" statement here: > https://github.com/jbalogh/test-utils/blob/master/test_utils/__init__.py#L109 > > cursor.execute('SET CONSTRAINT ALL DEFERRED') > > It didn't help. This might be related to ticket [1]#11665, a knownissue in the TestCase handling of constraints with pg. Suggestion athere si to use SET CONSTRAINTS ALL IMMEDIATE before the rollback. HTH -- Ramiro Morales 1. https://code.djangoproject.com/ticket/11665 -- 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.