Re: JsonResponse have a DEFAULT_JSON_ENCODER setting
I think that seems like a good thing to be able to configure. On Thursday, June 23, 2022 at 7:54:56 AM UTC-7 Fab wrote: > Hey, > > With JsonResponse instead of the encoder defaulting to DjangoJSONEncoder I > was thinking it would be nice to have a setting like DEFAULT_JSON_ENCODER > so I can set another one if needed without having to change all my usages > already set. > > > https://github.com/django/django/blob/0dd29209091280ccf34e07c9468746c396b7778e/django/http/response.py#L676 > > Is there any reason not to do this? Feels like it wont break backwards > compatibility. > > Regards, > > Fab > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0eff9638-f455-4a64-a507-b47c6bd2cff0n%40googlegroups.com.
Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()
It is a common idiom to use `.filter(<...>).first()` as a replacement for `.get(<...>)` when `None` is wanted instead of an exception when no match is found. That works, but wouldn't the intention be more clear if that could be written as something like .checked(False).get(<...>) -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d5802d27-0f60-4d52-93e9-953b571c9d41n%40googlegroups.com.
Admin: Allow FilterSpecs to return Q-likes
https://code.djangoproject.com/ticket/27303#trac-add-comment Hi all, I am looking to drum up more feedback about this issue as I think an important design decision needs to be made regarding filtering in the admin. At the heart of this issue is the syntax simplicity of repeating filter() clauses on a queryset breaks down pretty quickly when you are talking about traversing relations. The current FilterSpec API was a huge improvement, but shuttling filter() clauses between objects leaves a lot to be desired in terms of joining and leaves what I see as a critical inconsistency when it comes to adding several filters across relations (the way it is now, each filter gets its own JOIN and the result is a rather ambiguous OR-like clause). There are also related issues at play, such as providing hooks for developers to apply filters that do more than just AND. While my ticket doesn't hope to address that comprehensively, I do think that some interesting options come into play when we stop authoring FilterSpecs to chain filters() and instead return Q-like objects which are then applied by the ModelAdmin or AdminSite. -Steve -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/48f5411d-bcf2-4af3-b863-0dd6484618a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [RFC] Test methods filtering on tests run
On Tuesday, May 17, 2016 at 11:06:43 AM UTC+1, ludovic coues wrote: > > I might be saying something stupid, but rather than filtering test, > would it not be better to have a flag to rerun all the test that > failed in the previous run ? > > That's why we extende DiscoverRunner to make https://pypi.python.org/pypi/django-juno-testrunner It's not the best code, but it works well for us. Maybe something in this pattern (ie, a flag to generate and consume a rerun log) might be another way? Steve > So the command would always be the same for testA, testB or even both, > and might be more user-friendly if there is a bunch of test failing. > > 2016-05-17 2:32 GMT+02:00 Josh Smeaton >: > > > Hi Antonio > > > > I have the same problem when running tests in Django's test suite. When > > there's a failure, I have to copy the test path, paste that, then copy > the > > failing test. The entire path to the test isn't printed in the failures. > I'd > > be a big fan of *some* kind of implementation that allows me to filter > test > > methods. I think I'd prefer some kind of glob syntax though, so I could > do: > > > > ./manage.py test app_package**test_method > > > > That would allow you to be as targeted as you needed to be. > > > > Would you mind posting your patch somewhere? Reviewing code along with > the > > description and seeing potential for changes would be cool. > > > > Josh > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "Django developers (Contributions to Django itself)" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to django-develop...@googlegroups.com . > > To post to this group, send email to django-d...@googlegroups.com > . > > Visit this group at https://groups.google.com/group/django-developers. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/django-developers/0f9fc55e-9568-41d1-92f9-79effabd8e4b%40googlegroups.com. > > > > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > Cordialement, Coues Ludovic > +336 148 743 42 > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ed326169-0ec6-481d-bf12-8adb0a0d7d9d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: set `object = None` on `SingleObjectMixin`
I still haven't seen a definitive reason *why* the mixin doesn't do the check for the object, other than: 'Personally, I don't like this change' Shouldn't the mixin stand on its own and not require going to the django docs to find the dependency that the user needs to set self.object in get/post/etc? This same class even does checks for other attributes - e.g. raising an exception if the model class isn't set. It also sets `queryset = None`, so why wouldn't it do the same for `object`? On Friday, August 14, 2015 at 2:38:59 PM UTC-7, Tim Graham wrote: > > Yes, the proposal isn't new. Here is some related discussion: > * https://code.djangoproject.com/ticket/21801 > * https://github.com/django/django/pull/2260 > * https://github.com/django/django/pull/4595 > * https://github.com/django/django/pull/4526 > > On Friday, August 14, 2015 at 3:38:58 PM UTC-4, steve byerly wrote: >> >> In the `SingleObjectMixin` generic view mixin, the `get_context_data` >> method checks if the object is set by using: `if self.object` >> >> I often include this mixin just for the `get_object` functionality and >> error handing it brings. I end up having to set `object = foo` or `object = >> None` to suppress the AttributeError >> >> It seems like the class should initialize `self.object = None` instead of >> relying on a derived class setting it, especially because it doesn't >> guarantee that it will be added to the context - it only adds 'object' (and >> whatever the `context_object_name` param is) to the context if there's an >> object to add. >> >> I'm sure there has been discussion on this before, but I was unable to >> find it here/trac. >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop 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/74d3ba9d-9236-4918-a7b3-64c10421691e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
set `object = None` on `SingleObjectMixin`
In the `SingleObjectMixin` generic view mixin, the `get_context_data` method checks if the object is set by using: `if self.object` I often include this mixin just for the `get_object` functionality and error handing it brings. I end up having to set `object = foo` or `object = None` to suppress the AttributeError It seems like the class should initialize `self.object = None` instead of relying on a derived class setting it, especially because it doesn't guarantee that it will be added to the context - it only adds 'object' (and whatever the `context_object_name` param is) to the context if there's an object to add. I'm sure there has been discussion on this before, but I was unable to find it here/trac. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop 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/433f75a1-6709-4448-89a0-d1bd7ca7d3b4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Ideas for migrations squashing improvements
Yep, the issue I've been having is squashing more than one app. Once I've got my head around it, i'll write it up and poss submit a documentation ticket to help On 22 May 2015 at 12:05, Piotr Maliński wrote: > It should allow squash all migrations of one app without any dependencies > issues. Squashing may have problems if a model was created and later > removed or when removing RunPython/SQL operations or when reordering > operations to make the optimizer merge them into less operations (like > getting bad order for FK, M2M operations). > > > W dniu piątek, 22 maja 2015 10:49:11 UTC+2 użytkownik Steve Jalim napisał: >> >> Amen to 3 and 3a - that's been proving one of the fiddliest aspects when >> there are lots of migrations to squash - trial-end-error checking of how >> many you can get away with squashing in one go while avoiding dependency >> issues from other apps >> >> On Thursday, May 21, 2015 at 11:08:42 AM UTC+1, Piotr Maliński wrote: >>> >>> I made some tricky migration squashing in few projects recently. It >>> works but still could be made better. >>> >>> 1. squashed migrations could have explicit flag indicating that it's a >>> squash-initial migration. More complex squashes or optimizing squash can >>> lead to problems when it will not fake but try to apply on existing >>> database. Global --fake isn't a handy solutions for some deployment >>> solutions. Or just fake every 0001* migration if any other 0001* migration >>> was applied for given app in the past. >>> 2. there could be a "resquash" option that would not make a squash of a >>> squash but just optimize operations if possible for given squash >>> (application with one migration that is a squash). >>> 3. there could be a "testmigrations" command/option that would try to >>> migrate everything on a test database (or just given application with >>> dependencies) - similar to running some test just to get the migrations >>> going. >>> 3a. As a bonus - check if database schema is the same when migrated with >>> old squash versus new optimized squash. >>> >>> -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/vtf-4II-rEo/unsubscribe > . > To unsubscribe from this group and all its topics, 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/31f44414-b1f6-4451-810e-6505deb1db9e%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/31f44414-b1f6-4451-810e-6505deb1db9e%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop 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/CADJx9E9ySVJYvGM5rNKyeyz6ZKjbyOm_KHeJdXOzbXsvgprjwA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Ideas for migrations squashing improvements
Amen to 3 and 3a - that's been proving one of the fiddliest aspects when there are lots of migrations to squash - trial-end-error checking of how many you can get away with squashing in one go while avoiding dependency issues from other apps On Thursday, May 21, 2015 at 11:08:42 AM UTC+1, Piotr Maliński wrote: > > I made some tricky migration squashing in few projects recently. It works > but still could be made better. > > 1. squashed migrations could have explicit flag indicating that it's a > squash-initial migration. More complex squashes or optimizing squash can > lead to problems when it will not fake but try to apply on existing > database. Global --fake isn't a handy solutions for some deployment > solutions. Or just fake every 0001* migration if any other 0001* migration > was applied for given app in the past. > 2. there could be a "resquash" option that would not make a squash of a > squash but just optimize operations if possible for given squash > (application with one migration that is a squash). > 3. there could be a "testmigrations" command/option that would try to > migrate everything on a test database (or just given application with > dependencies) - similar to running some test just to get the migrations > going. > 3a. As a bonus - check if database schema is the same when migrated with > old squash versus new optimized squash. > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop 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/ba0832f2-51df-47e4-89e9-5c46d3ad6e29%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Capturing faked migrations in django_migrations table
Awesome, thank you very much for the detailed answer. -Steve On Tue, May 19, 2015 at 4:16 PM, Shai Berger wrote: > Hi Steve, > > On Wednesday 20 May 2015 01:50:15 steve byerly wrote: > > > > I'm also unclear what the argument against storing in the migrations > table > > is vs logging them - honest question. Since I have 4 web servers, the > > information would be logged to any one of them - depending on which > > executed the migration during deploy. > > > > The argument is, basically, that logging solves a more general use-case, > and > so it is a better solution for the problem. > > Your use case, as you described it: > > > During a deploy, it's really nice to make sure you faked the right > > migrations/didn't fake the wrong migrations > > fits in the general pattern of "I want to know what happened in this > system". > Logging, as far as we understand, solves that problem. The migrations table > solves a different problem -- it records which migrations the system > considers > to have been executed, to support the decision of which migrations to run > (when asked to). One of the outstanding "conflicts" between the two goals > is > encountered when a migration is rolled back: For "decision support", the > simplest handling is to delete the migration's record from the table (and > this > is what Django does, AFAIK). For "forensics", this behavior is quite > unacceptable. > > The most natural solution for knowing what happened in a system is logging. > When you have 4 servers, you want some federated logging anyway -- > migrations > are probably not the only case where something that happens on one server > affects the behavior of others. Be that as it may, Python's logging library > allows you to set different handlers for different loggers -- so, assuming > migrations get their own logger, it shouldn't be very hard to set up > logging > so that all migration logging goes to some special place. That place can > even > be the database -- see e.g. https://pypi.python.org/pypi/django-logdb (I > have > no personal experience with that package, I just searched for it). > > HTH, > Shai. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop 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/CAMN2zBMsQS6ryQEwTCvFB6AReaCgTYzFwHc74vUYh%3DcqXKMvoA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Capturing faked migrations in django_migrations table
Sorry all, i didn't get notified of the replies. I guess I assumed that since you are already capturing the applied migrations in the database, why not also capture if it was faked or not? In the case I outlined in the original post, there were initial migrations (0001, 0002, 0003) and new migrations (0002, 0003). During a deploy, it's really nice to make sure you faked the right migrations/didn't fake the wrong migrations since it will not auto-fake this scenario - unless I'm missing something. I'm also unclear what the argument against storing in the migrations table is vs logging them - honest question. Since I have 4 web servers, the information would be logged to any one of them - depending on which executed the migration during deploy. On Wednesday, May 13, 2015 at 4:58:45 PM UTC-7, Markus Holtermann wrote: > > I think having the Python logging module outputting the things the > migrations framework does, seems to be a good idea. I can see some use > cases where people want to turn that on. > > I opened an issue to keep track of the feature request: > https://code.djangoproject.com/ticket/24800 > > /Markus > > On Thursday, May 14, 2015 at 1:39:02 AM UTC+2, Andrew Godwin wrote: >> >> I agree a log would be helpful, but I'm not sure that should be stored in >> the database? We could either add a history/audit table in the database or >> we could have some way of configuring a logger that stores locally (which >> is a much higher bar, but presumably where sysadmins actually want logs?) >> >> Andrew >> >> On Wed, May 13, 2015 at 2:05 PM, Shai Berger wrote: >> >>> I think we had this discussion, more-or-less, around South migrations (I >>> looked a little, but couldn't find it). The context there was, as Tim >>> hinted, >>> "forensics" -- trying to figure out how a system came into its (broken) >>> state. >>> For that (as well as the OP's case, AFAICT) it makes little sense to add >>> a flag >>> in the migration history (really, "applied migrations") table, but it >>> does >>> make sense to have some sort of "migrations log", which would have a >>> record >>> for every migration executed (including backwards). >>> >>> Shai. >>> >>> On Wednesday 13 May 2015 20:34:19 Andrew Godwin wrote: >>> > I agree with Markus/Tim - the whole point of faked migrations is that >>> > they're meant to exactly match the existing schema. If Django is >>> > auto-faking migrations that don't match the existing one that would be >>> a >>> > bug, but it's almost too conservative in that aspect. >>> > >>> > Are you manually faking these migrations? Or having Django do it for >>> you >>> > and getting it wrong? >>> > >>> > Andrew >>> > >>> > On Wed, May 13, 2015 at 10:27 AM, Markus Holtermann < >>> > >>> > in...@markusholtermann.eu> wrote: >>> > > Hi Steve, >>> > > >>> > > apart from what Tim said, since you commit the migration files as >>> part >>> > > of the apps' code to your source code version control system, you can >>> > > simply have a look at the commit dates there. I'm not convinced >>> having a >>> > > marker for faked migrations in the database is useful. >>> > > >>> > > /Markus >>> > > >>> > > On Wed, May 13, 2015 at 10:20:15AM -0700, Tim Graham wrote: >>> > >> I'm curious to know the reason why it would be helpful to know >>> whether >>> > >> or not a migration was faked. When you fake a migration, you are >>> > >> promising that your schema matches the migration, so it seems to me >>> > >> that it would only matter if you made a mistake there. >>> > >> >>> > >> On Wednesday, May 13, 2015 at 12:38:38 PM UTC-4, steve byerly wrote: >>> > >>> I couldn't find any related discussions on this topic, but I would >>> find >>> > >>> it >>> > >>> helpful to have documentation whether a specific migration was >>> faked or >>> > >>> not. This would allow someone to look at all migrations that have >>> been >>> > >>> run >>> > >>> and see which ones were actually applied. >>> > >>> >>> > >>> My use case is migr
Capturing faked migrations in django_migrations table
I couldn't find any related discussions on this topic, but I would find it helpful to have documentation whether a specific migration was faked or not. This would allow someone to look at all migrations that have been run and see which ones were actually applied. My use case is migrating a large project to django 1.7. Since there are many apps in the project the initial migrations generated are not all 0001 - 0002, 0003 both present. These will all get faked, but it's not obvious in 6 months that migration 0003 in one app that was created as part of initializing migrations was faked vs migration 0003 in another app that was applied. Adding a NullBooleanField to the model would solve the issue, but I'm not positive if this is good practice. Thanks for the input in advance. -Steve -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop 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/0cb6be5f-a957-4580-9b17-a034706e87ba%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Cleaning up broken pipe errors in runserver
Naive / over-obvious suggestion: if there's a genuine stalemate, bundling the changes into a third-party app that supplants core runserver (similar to how django-devserver does it) would avoid the need for individuals to monkey-patch while also making it possible to release versions with more significant security fixes based on changes to the underlying Python -- without tying it to core Django at all. It also puts the decision on the developer re whether or not to care about the "fixed" runserver being slightly less secure. In a way, it's punting the issue, but I'm all for anything that "fixes" the broken pipe handling: if the fixed runserver existed as a third party app today, I'd install it. And better than the issue tanking for another few years. If if then gets enough traction, that opens a case for it core re-consideration, potentially. Yup? S On Monday, November 3, 2014 6:20:35 PM UTC, Tim Graham wrote: > > I had a look at the patch. As I mentioned on the ticket, "I am not really > happy with that patch which copies the > simple_server.WSGIRequestHandler.handle() method from Python's version in > order to override it. The copied version is not in sync with the latest > Python and I'd prefer not to be in a position where we'd have to copy > changes from there to Django." > > Matthew noted, "the change [in WSGIRequestHandler.handle()], made only > last month (hence why this PR doesn't currently match it), is the only > change to that function since it became part of the standard library in > 2006, and is a small potential security issue that doesn't apply to a > development server in any case, as that's explicitly listed as being > insecure. I don't necessarily think you'd have to keep changes in sync from > upstream, as I don't see there would be any changes to this function other > than other tiny security issues that don't matter to a development server, > but I can see you wouldn't want to be in that potential situation anyway." > > I agree with that, however, many people do use runserver in production and > several members of the core team feel we should fix security issues with > runserver even though the docs say it's not hardened for production use > (I'm not one of them). Any more opinions on how to proceed here? > > On Wednesday, August 27, 2014 12:52:38 PM UTC-4, Richard Eames wrote: >> >> I'm +1 for this, for the same reasons; I have a monkey patch for my >> selenium tests which does the same thing as this PR. >> >> On Saturday, 2 August 2014 18:20:18 UTC-6, Matthew Somerville wrote: >>> >>> Hi, >>> >>> I have created a branch at >>> https://github.com/dracos/django/compare/pipe-cleaning that builds upon >>> a previous patch posted to this list and outputs "Broken pipe" instead of a >>> traceback for such an error. As the history below shows, practically >>> speaking all reports of broken pipe tracebacks in the log are due to the >>> browser cutting off output, and are not helpful to be shown as a full >>> traceback. I get them frequently (e.g. hit refresh before your previous >>> page has finished loading to sometimes get it), and find them annoying. >>> >>> I am posting here because ticket # - >>> https://code.djangoproject.com/ticket/ - is marked wontfix. I am >>> not "imagei" on that ticket, I just came across the ticket recently whilst >>> trying to work out why my Selenium tests on Travis were failing with broken >>> pipes when they were fine last week - >>> https://github.com/travis-ci/travis-ci/issues/2610 (some change to >>> underlying Travis, I assume). Ticket # was opened in May 2007, and >>> marked wontfix in September 2007 saying "The best we could is to have a >>> more explicit error message." In 2008 someone provided a patch to make >>> it a logged error message rather than spew a scary traceback, there was a >>> +1 and a "leave as-is", then silence. There was a brief reopening of the >>> thread in 2012 by two people who also found the broken pipe tracebacks >>> tedious, then nothing further since then. The thread (2008 and 2012) can be >>> found at >>> https://groups.google.com/forum/#!topic/django-developers/W1Nns9k40EQ >>> >>> (The 'python manage.py runserver --help' is a little bit confusing >>> because it has a --traceback argument and yet you still get a traceback - >>> you have to have read the default options section of the django-admin.py >>> documentation to know that only makes a difference to CommandError, not any >>> other type of error. My branch also adds "CommandError" to the help output >>> of --traceback.) >>> >>> The 2008 patch doesn't really work any more, but I think I've made the >>> spirit of the same thing on the current Django code. I hope this can be >>> considered for inclusion, as I think it tidies up a common issue with >>> runserver output that will especially confuse people new to Django. Do let >>> me know if I've gone about fixing it in the wrong way, or if I should
Potential bug in select_related() as of Beta
Hello all, I believe select_related is creating some extraneous joins in situations where one is joining child models from a base model (model inheritance). Take the following SQL generated (dpaste here, probably more readable http://dpaste.com/160677/) SELECT (fields) FROM `base_contact` LEFT OUTER JOIN `consumer_consumer` ON (`base_contact`.`consumer_id` = `consumer_consumer`.`id`) # ok INNER JOIN `agency_program` ON (`base_contact`.`program_id` = `agency_program`.`id`) # ok LEFT OUTER JOIN `consumer_contact` ON (`base_contact`.`id` = `consumer_contact`.`base_id`) # ok INNER JOIN `base_contact` T5 ON (`consumer_contact`.`base_id` = T5.`id`) # ?!? # These next two are questionable, since they are joined on a LEFT OUTER (so they may potentially not be there) INNER JOIN `consumer_service` ON (`consumer_contact`.`service_id` = `consumer_service`.`id`) INNER JOIN `consumer_servicetype` ON (`consumer_service`.`type_id` = `consumer_servicetype`.`id`) LEFT OUTER JOIN `IR_contact` ON (`base_contact`.`id` = `IR_contact`.`base_id`) # ok INNER JOIN `base_contact` T9 ON (`IR_contact`.`base_id` = T9.`id`) # ?!? WHERE `consumer_consumer`.`file` = 06-1757 ORDER BY `base_contact`.`date` DESC There are two joins I simply can't explain (marked "?!?"). Removing them gives me my expected results. select_related in on case seems to correctly create a LEFT OUTER, but then follows up by creating an unwanted INNER. Keep in mind I made a note about the 'questionable' join above, but even removing that entirely creates the same problem. I'll be glad to file a ticket, if the issue is something other than my ignorance. -Steve -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
'str' object has no attribute '_default_manager' fix? (#10405)
http://code.djangoproject.com/ticket/10405#comment:10 Please forgive me (and point me to) if there's already a discussion about this bug. I wasn't able to find it. I linked above to Jacob's advice to 'just load Models before Forms'. Maybe there is an easy way to do this, but if there is, I do not know it. I find it unreasonable in all but the simplest (AKA tutorial) project. In a 50~ app suite which 12~ projects pool, I'm really not sure how best to make certain models is loaded before forms in every case. Could I perhaps get some further guidance? Thank you, -Steve --~--~-~--~~~---~--~~ 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: opening up RegexURLResolver
I totally agree that returning an object is the way to go. I know a lot of other folks are busy getting the next release out, but after that, I am happy to submit a proposed patch. I think it should be straightforward to preserve the current api while still adding new functionality. On Apr 18, 2009, at 4:55 AM, fas wrote: You can take this idea further by not providing the name but the resolver object. This gives you much more flexibility. [...] --~--~-~--~~~---~--~~ 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: opening up RegexURLResolver
> From: Ulrich Petri > > Am 16.04.2009 um 21:12 schrieb Steve Howell: > > http://www.djangosnippets.org/snippets/1444/ > > > > In writing this code, it occurs to me that other > advanced users might > > want more control over URL resolution, and it seems to > me that a > > valuable piece of information would be the "name" of > the URL, i.e. the > > same name that gets used for reverse mappings. > Then, if folks want to > > change the dispatch of URLs in some way, they can use > the name as a > > guide for adding extra parameters, using a different > callback, etc. > > So I'm wondering if it would make sense to have > URRegexResolver have > > an alternative to resolve() called resolve_with_name() > that returns > > not just the callback and arguments, but also the > name, and I suppose > > also the regex could be useful in some cases. > > > > I've had a similar need in the past and actually posted > something > similar to djangosnippets: > http://www.djangosnippets.org/snippets/1378/ > > Now that code is obviously a hack so don't look too hard > ;) > > But I think that maybe there is a need for some kind > of > resolve_to_name functionality. > Interesting...at least two of us were thinking along the same lines. For now I took the liberty of updating both of our snippets to reference the other in the comments. Cheers, Steve --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
opening up RegexURLResolver
I recently wrote some code to overcome the below limitation with the URL include mechanism: ''' Note that extra options will always be passed to every line in the included URLconf, regardless of whether the line's view actually accepts those options as valid. For this reason, this technique is only useful if you're certain that every view in the included URLconf accepts the extra options you're passing. ''' You can find more details here: http://www.djangosnippets.org/snippets/1444/ In writing this code, it occurs to me that other advanced users might want more control over URL resolution, and it seems to me that a valuable piece of information would be the "name" of the URL, i.e. the same name that gets used for reverse mappings. Then, if folks want to change the dispatch of URLs in some way, they can use the name as a guide for adding extra parameters, using a different callback, etc. So I'm wondering if it would make sense to have URRegexResolver have an alternative to resolve() called resolve_with_name() that returns not just the callback and arguments, but also the name, and I suppose also the regex could be useful in some cases. As my snippet is currently written, in order to change the dispatch for individual view functions, I have to hack into the internals more than I like. I don't think my code is too risky, but it would have been a lot simpler if I could have created a wrapper around URLRegexResolver with my own custom resolve() method that called URLRegexResolver.resolve_with_name() to do the heavy lifting. I'm not pushing hard for this feature...I am more interested in the discussion. I am still pretty new to Django, so I might be overlooking better ways to solve my problem. But I decided to post here, since I think a lot of what I'm interested in learning about are the internals and dev philosophy behind the current limitation. Cheers, Steve --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
PseudoField / Field-level query managers
Hello Djeople,
Trolling for criticism, broader use-cases, or a lurking solution for my
latest problem: Say you've got a model with two fields 'primary_lang' and
'secondary_lang' and you'd like to filter across them in one fell swoop. The
obvious solution is to make a manager method filterlang('foo') which
conducts a Q(primary_lang='foo')|Q(secondary_lang='foo') under the hood.
Fine and dandy until your boss asks you to create a Report Generator (or
something) which takes arbitrary fields from your model and wants to report
on them. Trying to get this generator to use your custom model method would
be a sinch, except the fields (primary_lang, secondary_lang) are totally
ignorant as to how they ought to be filtered.
You could override filter() (please, save your groans), but its not obvious
to later maintainers why it would work, and getting it to function for all
queries is tedious. See Also:Yak Shaving (Tredinnick, et al).
My thinking at this point is you could create a PseudoField which has its
own model manager-ish logic and attach it to the model, then somehow have
the model catch the FieldError which is certain to arise, and check for one
last hurrah among PseudoFields for results, and then returning them.
That's the best I got so far. Thoughts?
-Steve
--~--~-~--~~~---~--~~
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: Template-04's scope
Jacob Kaplan-Moss wrote:
> On Tue, Nov 25, 2008 at 10:11 AM, Johannes Dollinger
> [...]
>> * I always felt the API for custom tags is too verbose.
>>
>
> There's almost universal agreement on this point :)
>
> It's unfortunately pretty tricky to do in a backwards-compatible way:
> we've sorta pasted ourselves into a corner here by letting tags do
> anything they want in terms of parsing. This lead to an inconsistency
> in syntax that we (unfortunately) have to continue to support.
>
> However, that's no reason not to have a better API on top that
> third-party tags can use -- as long as internal tags don't break.
>
Heretical suggestion: {: :}, {! !}, {$ $} or {[ ]} with a different
processor (falling back to the original if necessary), and therefore no
need for a fully backwards-compatible approach?
regards
Steve
--~--~-~--~~~---~--~~
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: order_by with distinct behavior in orm
Malcolm Tredinnick wrote: [...] > Hopefully, MySQL will fix their bug one day. That's the way to resolve > this. > Just so long as nobody holds their breath waiting ... regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: Using a HTML to fire off a data processing script on the server (REST or SOAP)
Shao: This is a very general question, and is only indirectly connected to Django, since the task could be performed in most web frameworks. However, the django-dev list is reserved to discussions about the development *of* Django. For questions about development *with* Django you should address the django-users list. Thank you. regards Steve Shao wrote: > Dear ALL, > > I am very much interested in using a HTML to fire off a data > processing script to run over the internet. > > I will be very grateful if you can advise me on passing parameters > from an HTML form to a script and fire the script off to carry out > full execution, monitor its progress and return an innerHTML with link > (a name string of) the file generated back to allow user to download > the result. > > The script run over a period of 2 to 3 minutes. > > > Necessary are the following steps: > * user submits data to the server from a web page using an HTML form; > server redirects the browser to a status page that says "script is > running"; > * in the background, the server fires off a worker script that does > the job; the server monitors the script to see when it's done (this > monitoring can be tied to the status page: when the user reloads the > status page, the server looks at the script to check if it's done); > * user refreshes the page (or the page refreshes itself) until script > is finished, and the page says "script finished; here are the results" > * some kind of cleanup of data, either with a cron job or manually by > the user > > Regards. > > Shao > > > > > --~--~-~--~~~---~--~~ 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: Proposal: Composite Foreign Keys
the required changes could be made in less than 24 hours is a breathtaking oversimplification, however. If you believe it, then roll your own sleeves up and you could surely have it done by the end of the week. Open source, remember? This means that leadership is a bit like herding cats. I think you just took a good shot at pissing the cats off. regards Steve --~--~-~--~~~---~--~~ 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: Multi-Threaded Dev Server
Julian wrote: > [...] I think some people want to use snippets like that [...] Wouldn't you agree that's a pretty feeble use case for something as potentially disruptive as multi-threaded serving? Particularly when the CherryPy alternative is so readily available. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: Proposal: Composite Foreign Keys
Malcolm Tredinnick wrote: > On Thu, 2008-11-13 at 23:47 -0500, Steve Holden wrote: > [...] > >>> Maybe be you mean transparently. If so, I think this is a requirement, >>> too, but it's not a problem. We know when the ForeignKey field is >>> specified which model it refers to, so we can include the correct number >>> of database columns at table creation time. We have perfect information >>> when we create the table, which is where this differs from any generic >>> relations. >>> [...] >>> >> Does that apply even to recursive (reflexive) relationships, when the >> related model must be specified by name rather than by reference? I >> don't know enough about the internals to be clear on that, but it seems >> like it could be problematic. >> > > It needs to be taken into account, but it's certainly solvable and not > an obstacle to success. There are two solutions available: > > (1) Postpone creating the first table until we have read the second > table so that we know the number of columns. This isn't too hard, > although it means you end up making two passes over some classes' > internals in some cases. But table creation is such a rare event and the > Python code is so fast that it's easily affordable. We're not talking > about something changing from 15 minutes to 20 minutes or anything. > Sure. Perhaps it's not common terminology: by "recursive" I meant a self-referential relationship, though now you mention it I see that the same issue can occur if the order of model definitions is sub-optimal. > (2) The poor-man's approach is "ALTER TABLE", which is a small-ish > change, but butt ugly. I prefer the former solution, but the this is the > silly drop-in I've got at the moment just to make things possible to > develop with. > I can see why, from a purist point of view, you'd rather not use it. Doesn't mean it couldn't be useful as a first implementation, though. > Realise that the reason we have string-ified forwards references is to > avoid the need for circular imports. But at some point we'll end up > importing everything anyway and then we can go and look at the number of > required columns. This is why forwards references work in the first > place -- at a later time we go back and fix up the internal references > to point to the Python objects in question. We can change table creation > to operate similarly. It's not that hard. > > I understand that. I just don't have the smarts to be able to help right now, but thanks for the explanations. regards Steve --~--~-~--~~~---~--~~ 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: Proposal: Composite Foreign Keys
Malcolm Tredinnick wrote: > > On Thu, 2008-11-13 at 19:50 -0800, David Cramer wrote: >> I was thinking beyond just handling Foreign Keys actually when I wrote >> this up. It would allow for a more generic version of a generic >> foreign key. > > Generic relations are quite different to foreign keys and the two > shouldn't be merged. > > Generic Relations say how to get from an object id and a content type to > a remote object. They aren't a database-layer construct, although a > database constraint to, e.g., the content-type table could be > enforced(but that's not relevant here). ForeignKeys are a representation > of a database constraint, always referring to same remote table. They > are necessarily different concepts and I dont' think attempting to merge > them is going to gain much in clarity. At some point when multi-column > primary keys are supported, we might be able to work out a way for > generic relations to handle them, but I'm not holding my breath about > that and it's certainly a phase 2 or phase 3 thing. The reason it's > almost impossible to support generic relations with arbitrary > multi-column fields because the number of columns is, well, arbitrary > (attempting to jam multiple remote values into one local database column > is a bad idea, too. At some point the hacks mount up beyond the point of > usefulness). That is, one content type requires one value, a different > one requires two and a third content type might require four values to > identify the object. I strongly suspect we'll end up just saying > GenericRelation fields only work for single valued objects ids. Which > isn't at all unreasonable, since Django's generic relation classes > aren't really compulsory for data modelling. Any given situation has a > solution that doesn't involve them. > >> Although the more I think about it we'd still want to >> magically handle ForeignKey's so the same problem exists. > > There's no magic in programming. :-) > > Maybe be you mean transparently. If so, I think this is a requirement, > too, but it's not a problem. We know when the ForeignKey field is > specified which model it refers to, so we can include the correct number > of database columns at table creation time. We have perfect information > when we create the table, which is where this differs from any generic > relations. > [...] Does that apply even to recursive (reflexive) relationships, when the related model must be specified by name rather than by reference? I don't know enough about the internals to be clear on that, but it seems like it could be problematic. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: contrib.comments: working example must make a boost.
Valery wrote: > >> With a positive attitude like that I *really* hope you will be at the >> PyCon sprints next year! > > Chicago, IL -- uhhh, quite far... :) > Maybe so, but it *is* possible to apply for assistance with funding. Not all such requests can succeed, but you could consider applying. Keep your eye on us.pycon.org. > >> As far as Django's concerned I'm pretty much a >> user not a developer, but they do have a very knowledgeable and helpful >> community on both sides of the line. > > OK, Steve, consequences? I have a bad looking form after following the > trunk's wiki, in my form I can see - entries without any > tag at all and this all when those guru's are telling me > "tables is a bad thing, just let the content flow!" > > Ok, I am kinda equipped with a DIV-magic wand and am quite happy to > let the content flow, just let me know my contrib.comment- > friends are :) > I'm no CSS angel, but holdenweb.com now only uses a table layout for the home page. It does make the inner pages much more flexible. My latest attempt (as test.holdenweb.com) currently breaks in IE ... > Whatever friends, definitely, it is not the biggest prob we are > facing :) No, but for well-designed web systems good HTML and CSS is important. > I wish you a nice evening and a nice weekend coming. > > Looking forward to hearing from you > K hope you have a good weekend also. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: contrib.comments: working example must make a boost.
Valery wrote: > Hi all, @mtredinnick, @jacob, @wilson, @ubernostrum > > not sure if any "community boosts" are at all wanted here, but finally > django is not for a closed circle of django-gurus and things are for > the larger audience, isn't it? :) so, why there is no easy-to-launch > example of last contrib.comments code? > > Look, I've spent about 3 (three) hours in total on 1.searching the > example, 2. trying to get stable version somehow working according to > wiki, then 3. the "trunk" things running according to wiki.The stable > things are too old. The trunk's ones are too young. In the case of > contrib.comments as I see it now, I'd definitely stick to trunk. How > could one get it somehow usable? -- Examples are needed. > > A simple rule of mine regarding the community and bounce rate: > > * 1 person who is leaving after having no success in 3 hours equals > to: > > * 2 more pragmatic persons who stop after 1.5 hours of no success -- > and this is equal to: > > * 4 of even more pragmatic persons who stop after 45 min of no success > trying the things they need for their Goal... and? what does it > equal? :) > > * 8 pers and 25 mins ... > > * 16 pers and 15 mins > > * 32 pers and 10 mins > > * 64 pers and 5 min :) > > * 128 pers looking at WORKING live demo! > > * 256 pers who never seen even the demo but have been reading in blogs > how cool has been the experience about django and its > contrib.comments. > > Sum them all up. > > Just single me and those hundreds. I don't want really enter the long > discussions. I'd like to know how could I help getting such an example > running. (Of course, I have some work copy) > > With a positive attitude like that I *really* hope you will be at the PyCon sprints next year! As far as Django's concerned I'm pretty much a user not a developer, but they do have a very knowledgeable and helpful community on both sides of the line. regards Steve --~--~-~--~~~---~--~~ 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: 1.0.1 release blockers?
Karen Tracey wrote: > On Fri, Oct 31, 2008 at 6:38 AM, mrts <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > There has been much reluctancy in letting triagers tag and prioritize > 1.0.1 milestone tickets. Now that 1.0.1 is really close, can we > perhaps discuss what are the things that really should be fixed before > it is released? > > > Really, there is not reluctance to get input on what should be fixed > before 1.0.1 is released. It's just that input in the form of working > patches with tests and doc is far more valuable than a simple bit on a > ticket. The list of tickets that are ready for checkin is not so big > (and some of them are enhancements so not candidates for 1.0.1. > <http://1.0.1.>) that we need some other bit to say "look at this > before releasing 1.0.1". > > > The only major issue I have encountered is > http://code.djangoproject.com/ticket/8882 > that makes inline formsets that have unique fields (that is, pretty > much every other use case for them) unusable. Looks like brosner is > already working on it -- thanks! -- and it would be perhaps wasteful > if 1.0.1 is released before he has finished. > > > It really depends on how close a fix is as to whether it would be > worthwhile holding up a bugfix release on any one ticket. I'm not > talking about this ticket in particular (which I haven't looked at and > it sounds like it's already on others' radars so likely will get in, > assuming it's not too terribly difficult to fix) -- I'm trying to get > across that holding up a bugfix release in hopes of a not-yet-existent > fix for a bug that's already in a shipped release doesn't make much > sense, unless you've got some reason to believe a fix will be > appearing real soon now. There are already many bugs that have been > fixed in the 1.0.X branch and will benefit users. 1.0.1 will be > better than 1.0, and 1.0.1 released in the very near future with n-x > bugs fixed is better than 1.0.1 released at some unknown future data > with those those additional x bugs fixed. > Well right, that'll be 1.0.2 if it's needed. Though with 1.1 on the way it seems less than likely. regards Steve --~--~-~--~~~---~--~~ 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: Proposal: Optional {% default %} clause for the {% for %} template tag
Jacob Kaplan-Moss wrote:
> I'm with Steve::
>
> {% for %} ... {% default %} .. {% endfor %}
>
> ... seems best.
>
>
Agreement is great, but my suggestion was actually
{% for %} ... {% empty %} ... {% endfor %}
I feel this says more than "default", which requires you to think about
when the default value is required.
regards
Steve
--~--~-~--~~~---~--~~
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: Proposal: Optional {% default %} clause for the {% for %} template tag
Calvin Spealman wrote:
> On Wed, Oct 29, 2008 at 9:48 PM, Dave Smith <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> I'm wondering who that's going to confuse. It's very clear that
> the template language
> isn't Python, so I'd think it'd make the most sense to use a
> keyword that makes sense
> within the context of the template language. I'd think that either
> 'else' or 'ifnone' are the
> most memorable/readable. 'default' connotes "unless we override
> ...", which isn't what's
> going on here.
>
> +1 for else
>
>
> The template language may not be sold as "python in html" but there
> are still obvious relationships between the constructs the two share.
> Breaking assumptions then simply isn't good for anyone involved.
>
> +1 for a default, -1 for calling it else
>
+1 to both the +1 and the -1. It *will* confuse Python programmers who
also happen to write templates, and personally I think {% empty %}
expresses the meaning much more clearly to all classes of user.
regards
Steve
--~--~-~--~~~---~--~~
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: Determining the active urlpattern for navigational templates
Jesse Young wrote:
> I'm guessing it's somewhat common (as usual, I think it's common
> because I do it) to put several navigational links in a template that
> is included from several other templates, e.g.:
>
> Page 1
> Page 2
> ...
> Page N
>
> But also, it's helpful to indicate where the user currently is in the
> navigational hierarchy, e.g.:
>
> Page 1
> Page 2
> ...
> Page N
>
> With Django I don't know of a convenient built-in way to do this. One
> could copy and paste N slightly-different versions of the navigational
> links template, but that isn't maintainable. One could manually pass
> in an extra context parameter in each of the N views, and add {% if %}
> tests in the template for each of them, but that's tedious.
>
> What I want is the ability to write a custom template tag that uses
> the same parameters as the tag {% url pageN %}, but which acts as a
> conditional and does something different if the parameter matches the
> currently active urlpattern. E.g., I could write a block tag {%
> ifactive pageN %}:
>
> Page 1
> Page 2
> ...
> Page N
>
> It doesn't seem like this can be done with standard Django because the
> request doesn't have a reference to the URL pattern that was actually
> used. My idea (implemented in my local version of Django) was to
> modify RegexURLResolver to return the urlpattern that was used, and
> store that (as well as the kwargs) as a property of the request.
>
> Does this seem like a useful patch? Or is there a better way to
> accomplish this?
>
Some general advice, which may not all be relevant to your specific
circumstances. While including templates has its place, it's often
simpler and easier to use template inheritance ("{% extends ... %}")
instead. Look at context managers. You want to avoid doing as much of
that stuff in templates as you possibly can - it can get ugly real
quick, whereas in pure Python it's much more natural to express that
sort of thing.
Have the context manager build an appropriate list for the specific
page, and then just have the template render whatever list the context
manager builds. There's a balance to be struck between template
complexity and Python complexity.
This can also keep your template structures simpler. In holdenweb.com
more of the pages are stored in the database, and each page can be
associated with a section. You will notice, for example, on
http://holdenweb.com/contact/
that the "Contact Holden Web" link in the left-hand nav bar isn't
actually a link (I have an aversion to self-linking pages). The part of
the context manager that builds the left-hand nav data reads
lNavSecs = Section.objects.filter(secpos="L").order_by("secsequence")
for sec in lNavSecs:
sec.pages = Page.objects.filter(pagsecid=sec.secid). \
exclude(pagsequence=0).order_by("pagsequence")
hpdict["lNavSecs"] = lNavSecs
The navigation is rendered in the base template, which all other site
pages (except the front page) extend, and the template section that
renders it reads
{% for sec in lNavSecs %}
{% for p in sec.pages %}
{% ifequal path p.pagpath %}
{{ p.pagdoctitle }}
{% else %}
{{ p.pagdoctitle }}
{% endifequal %}
{% endfor %}
{% endfor %}
It's usually easier to iterate over a sequence of some kind than putting
lots of special-cased stuff in the template.
Hope this helps.
regards
Steve
--~--~-~--~~~---~--~~
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: GET requests should not alter data?
Amit Upadhyay wrote: > On Wed, Oct 15, 2008 at 5:17 PM, Ivan Sagalaev > <[EMAIL PROTECTED]> wrote: > >> Amit Upadhyay wrote: >> >>> This is not about specs or what is allowed, rather what is there in >>> actual django. And about implementation goals for django. It is >>> possible to have a django(core+contrib apps shipped with django) with >>> only SELECT queries in response for GET request. So far I have >>> identified two places and their work arounds. Are there more? They >>> should be avoided, and if not possible documented. >>> >> For example you can't implement OpenID consumer without altering >> application state on GET (actually logging a user in happens upon HTTP >> redirect). >> > > Its necessary given openid spec I guess. Can it be worked around by > not splitting GET/POST for urls starting with /openid/? Can a GET on > That's a pretty fragile test. What happens if I decide to start my URLs with /Openid/, or /authenticate/openid/, or ... ? > any request, thanks to some middleware maybe, write or writes are > limited to one of few URLs? Such questions are not easy to answer > offhand for someone who is using the app, and should be can go > somewhere in readme.scaling.txt/less frequently asked question for the > app may be. Along with other resources, files/directories etc that may > be used by openid consumer, from the point of view of scaling. > While I can see the generic desirability of GET requests not making database writes there are always going to be exceptions. Let's not pursue this as a purist goal, but rather for the sound pragmatic reasons that have already been elucidated. regards Steve --~--~-~--~~~---~--~~ 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: Python 2.6 abstract base classes
Malcolm Tredinnick wrote:
> On Thu, 2008-10-02 at 10:32 -0400, Marty Alchin wrote:
>
>> Looking over the new things in Python 2.6, I wonder if there are plans
>> to inherit from any of the new abstract base classes in Django. It
>> looks (to me) like it could be backwards-compatible, using an import
>> like so:
>>
>> try:
>> from collections import Sequence
>> except ImportError:
>> # Fallback for Python 2.5
>> Sequence = type('Sequence', (object,), {})
>>
>> Django obviously works just fine without these at the moment, so
>> there's no pressing need to do so, but if they catch on and 2.6+
>> libraries start checking for them, it might be beneficial if some of
>> our custom types, like QuerySets, inherited the appropriate classes.
>>
>
> How about we wait until that looks like maybe happening, then? Python
> 2.6 is approximately 43 seconds old and there isn't a lot of real-world
> experience with the traps and benefits of using this approach yet.
> Hopefully people writing 2.6 code won't be deliberately making it
> difficult for code that is portable across more than the "latest
> hotness" version to function and we can avoid having to add four lines
> of relatively confusing line-noise to our import statements.
>
> Python code should be readable. The above code fragment fails that test
> and whilst we have some similar code for other backwards compatibility
> reasons, the existing cases are requirements. This one is optional, so
> I'd much rather avoid it for now.
>
+1
Trendy might be superficially appealing, but I personally felt 2.6 would
have been just as useful without the ABC backport.
regards
Steve
--~--~-~--~~~---~--~~
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: Denormalisation, magic, and is it really that useful?
This appears to be a proposal to re-implement triggers inside Django.
I can see there are benefits if the underlying DB platform won't support
triggers, but wouldn't triggers be the preferred solution when they're
available? That way there is no chance that changes can be made outside
the scope of the denormalization, and hence no need to recompute the
denormalized values.
regards
Steve
Andrew Godwin wrote:
> David Cramer wrote:
>
>> If you're not doing denormalization in your database, most likely
>> you're doing something wrong. I really like the approach that is
>> offered here.
>>
>> For me, personally, it would be great if this could accept callables
>> as well. So you could store the username, like so, or you could store
>> a choices field like:
>>
>> field = models.IntegerField(choices=CHOICES)
>> denorm = models.DenormField('self', 'get_field_display') # which
>> would rock if it was .field.display ;)
>>
>> You could also make it somehow accept querysets or something similar
>> for things like count(). I see a lot of possibilities and am a bit
>> disappointed I didn't come up with something this easy for my use-
>> cases.
>>
>>
>
> The key is making sure you can listen for changes on whatever's at the
> other end of your denormalisation. With my current snippet, it listens
> for a save on the model the foreignkey points to, then checks for the
> right ID; if we start accepting random querysets, then there has to be a
> way to resolve that back to conditions the signal listener can understand.
>
> Still, with an
> AggregateField(Sandwiches.filter(filling="cheese").count()) it's still
> possible to work out that you want to listen on the Sandwiches model,
> and you could then fall back to re-running the count on every Sandwich
> save, even if it ends up not having a cheese filling.
>
> So, I think the best approach would be one to replicate fields (like my
> current DenormField; perhaps call it CopyField or something) and one to
> cache aggregates (an AggregateField, like above).
>
> Simon Willison wrote:
>
>> Just so it's on the record, I'd like any denormalisation tools in
>> Django to include a mechanism for re-syncronizing them should
>> something go awry (like direct updates being applied to the database
>> without keeping the denormalised fields in sync). This mechanism could
>> then be exposed as a ./manage.py command which could be called
>> periodically to verify and fix any incorrect data.
>>
> Yes, this I very much agree with. The reason you always layer this stuff
> on top of a pre-normalised database is because you can then rebuild the
> data after playing with it externally.
>
> Doing so shouldn't be too much of a problem; have a management command
> that loads the models, and then just executes the update method on each
> of the denormalisationalish fields.
>
> Justin's idea of lazy updating is interesting, and probably quite doable
> (as well as what most people will want by default on aggregate queries).
>
> I'm also hoping any kind of aggregate denormalisation will work with any
> future extended aggregate support, but if the field just takes a normal
> QuerySet, that might Just Work™.
>
> Andrew
>
>
> >
>
>
--~--~-~--~~~---~--~~
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: [Fwd: Documentation: Google-foo lost]
Steve Holden wrote: > Jacob Kaplan-Moss wrote: >> On Fri, Sep 19, 2008 at 2:19 AM, Steve Holden <[EMAIL PROTECTED]> wrote: >> >>> The question is: is it worth continuing this web-scraping and analysis >>> and potentially extending it to other reference mechanisms I am unaware >>> of? I don't know whether the current redirection will eventually cause >>> the web search engines to throw away the old references, but it would be >>> nice to be able to move them forward if possible. >>> >> Yes, this is extremely helpful. I'd like to get some better redirects >> in place ASAP, so if you can work with your script to give me a >> complete list I can throw 'em up. I've done a couple of things for >> anyone who can help: >> >> * I've temporarily removed the global redirect; it's just confusing. >> We'll replace it with more granular redirects a bit later. >> >> * I've added a page to the wiki for redirects: >> http://code.djangoproject.com/wiki/DocumentationRedirects >> >> * I'll start writing some code to help with the redirects. We'll need >> a bit of javascript to help with the fragment redirects since the web >> server doesn't get fragments; I'll get that done. >> >> Monday morning I'm going to replace the redirects with whatever's at >> the wiki page. >> >> > I re-did the work starting with the pre-refactor docs instead of the > 0.96 ones, and I've added almost 1,000 redirects to the Wiki page. These > are all based on id's, let me know if there's anything else I > should look at before Monday. > It looks as though the global redirect may have been there long enough to start Google replacing some of the original content now, I'm sorry to say. I just searched for django http redirect and the first hit was the root page of docs.djangoproject.com :( -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: [Fwd: Documentation: Google-foo lost]
Jacob Kaplan-Moss wrote: > On Fri, Sep 19, 2008 at 2:19 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > >> The question is: is it worth continuing this web-scraping and analysis >> and potentially extending it to other reference mechanisms I am unaware >> of? I don't know whether the current redirection will eventually cause >> the web search engines to throw away the old references, but it would be >> nice to be able to move them forward if possible. >> > > Yes, this is extremely helpful. I'd like to get some better redirects > in place ASAP, so if you can work with your script to give me a > complete list I can throw 'em up. I've done a couple of things for > anyone who can help: > > * I've temporarily removed the global redirect; it's just confusing. > We'll replace it with more granular redirects a bit later. > > * I've added a page to the wiki for redirects: > http://code.djangoproject.com/wiki/DocumentationRedirects > > * I'll start writing some code to help with the redirects. We'll need > a bit of javascript to help with the fragment redirects since the web > server doesn't get fragments; I'll get that done. > > Monday morning I'm going to replace the redirects with whatever's at > the wiki page. > > I re-did the work starting with the pre-refactor docs instead of the 0.96 ones, and I've added almost 1,000 redirects to the Wiki page. These are all based on id's, let me know if there's anything else I should look at before Monday. regards Steve --~--~-~--~~~---~--~~ 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: [Fwd: Documentation: Google-foo lost]
Jacob Kaplan-Moss wrote: > On Fri, Sep 19, 2008 at 2:19 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > >> The question is: is it worth continuing this web-scraping and analysis >> and potentially extending it to other reference mechanisms I am unaware >> of? I don't know whether the current redirection will eventually cause >> the web search engines to throw away the old references, but it would be >> nice to be able to move them forward if possible. >> > > Yes, this is extremely helpful. I'd like to get some better redirects > in place ASAP, so if you can work with your script to give me a > complete list I can throw 'em up. I've done a couple of things for > anyone who can help: > > * I've temporarily removed the global redirect; it's just confusing. > We'll replace it with more granular redirects a bit later. > > * I've added a page to the wiki for redirects: > http://code.djangoproject.com/wiki/DocumentationRedirects > > * I'll start writing some code to help with the redirects. We'll need > a bit of javascript to help with the fragment redirects since the web > server doesn't get fragments; I'll get that done. > > Monday morning I'm going to replace the redirects with whatever's at > the wiki page. > Great. What else do I need to look for besides the section-class divs? I can put a little more time in to this over the weekend. Documentation needs at least as much love as code ... regards Steve --~--~-~--~~~---~--~~ 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: [Fwd: Documentation: Google-foo lost]
Don Spaulding wrote: > > > On Tue, Sep 16, 2008 at 2:20 PM, Don Spaulding > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > > Hope it's useful! > > > > and of course it isn't. I forgot my lambdas. Doh! > That's a great start. I noticed that many Google links are to fragments, and wondered if we could do some sort of recognition on them. It turned out to be interesting, as I was hadn't realised the documentation doesn't implement fragment references in the expected way. I pulled down the current documentation and the 0.96 stuff with websucker - I think it broke before it got quite all the old stuff, but the majority is present. The work I have done would really best be done on the final version of the pre-1.0 documentation before it was converted to the new organization, but I couldn't find that. So far I've only looked at the section headings, which can be located easily as . There are 119 sections like general-questions genericsitemap specialities-of-django-translation definitive-urls creating-models installation-questions template-inheritance overriding-default-model-methods less-code and serialization-formats which don't seem to appear (as sections) in the new documentation. So it's goodbye to them unless they appear as other structures in the new documentation. There are apparently 678 newly-minted sections like module-django.forms.fields using-generic-relations-as-an-inline inherited-models onetoonefield extra-methods-on-managers-when-used-in-a-foreignkey-context post-delete inlinemodeladmin-objects module-django.test module-django.http and the-file-object that never appeared (as sections) in the old documentation, so we don't need to worry about them unless they appeared as tags on some other type of object. The *good* news is that there appear to be 789 sections that can be redirected (hopefully with 301s, so Google and pals will pick up the new locations), of which a few examples are: Tag requesting-features was: ./contributing/index.html now: dev/internals/contributing/index.html Tag font-sizes was: ./admin_css/index.html now: dev/obsolete/admin-css/index.html Tag relationships was: ./model-api/index.html now: dev/topics/db/models/index.html Tag phone2numeric was: ./templates/index.html now: dev/ref/templates/builtins/index.html Tag pprint was: ./templates/index.html now: dev/ref/templates/builtins/index.html Tag restarting-the-spawned-server was: ./fastcgi/index.html now: dev/howto/deployment/fastcgi/index.html Tag basics was: ./templates_python/index.html now: dev/ref/templates/api/index.html Tag how-to-add-change-and-delete-redirects was: ./redirects/index.html now: dev/ref/contrib/redirects/index.html Tag seeing-which-settings-you-ve-changed was: ./settings/index.html now: dev/topics/settings/index.html Tag custom-default-settings was: ./settings/index.html now: dev/topics/settings/index.html Sorry that the old and new references aren't strictly comparable: this has been a spare time project in a rather busy week. I'm sure it's fairly obvious where they can be found. The question is: is it worth continuing this web-scraping and analysis and potentially extending it to other reference mechanisms I am unaware of? I don't know whether the current redirection will eventually cause the web search engines to throw away the old references, but it would be nice to be able to move them forward if possible. regards Steve --~--~-~--~~~---~--~~ 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: I want a pony: Django Cheeseshop
Malcolm Tredinnick wrote: > On Tue, 2008-09-16 at 05:06 -0700, mrts wrote: > > [...] >> setuptools is a necessary evil for the agile developer who frequently >> tracks updates for the bits he relies upon. Hopefully it will be >> improved (the clamor around it is ever-ongoing), but unless we want to >> do it ourselves, we have to accept the state of things. >> > > Wow. You just said we should entirely ditch security because it isn't > convenient. That's exactly the attitude that has made Microsoft the > laughing stock of the professional IT community for the last 15 years. > > Which, sadly, hasn't affected either their profits or their market dominance. > If my original mail had said "nobody should ever use setup tools" or > anything like that, you reply might be valid. Go back and read it. I > said "optional", not "forbidden". There are multiple audiences here. If > Django ever had a hard dependency on setuptools for using third-party > packages it would make it very difficult for system administrators to > use Django because of the large level of security uncertainty and extra > overhead that comes with using it. So, again, it's fine for people who > want to to use setuptools and virtualenv and buildout and eggs and > rinky-dinky-tool-of-choice. People use things knowing that there are > always trade-offs and compromises. It's bad once policy starts being > enforced on something that is simply unusable in certain environments. > Yes, anyone looking for "the one true way" is doomed to disappointment. You only have to review recent correspondence on python-dev to realize that no one person is aware of all the requirements of the various platforms for which modern applications must be packaged. I don't much like the pejorative implication of matching "rinky-dinky-tool-of-choice" with the other listed alternative, however. Personally I think virtualenv is a good solution to a tricky problem. The thing that bugs me most of all is Python developers who assume that the answer to all Python distribution problems is the assumption that a single Python installation can support all required applications. In this day and age it's quite practical to look at distributing the required interpreter as a component of your application or framework. There is no reason why your Python program and mine need have any components in common, and increasingly less reason to enforce this requirement to save disk space. Having said which, Django and other frameworks don't have that luxury: if I'm running Django on 2.4 then every app my Django installation supports also has to run on 2.4. regards Steve --~--~-~--~~~---~--~~ 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: Install over old level produces mutant
Fredrik Lundh wrote: > Karen Tracey wrote: > > >> We've had at least three people run into a problem (#9090) after >> installing 1.0 over an old level. Now, we do document that before >> installing you should remove any old level. But I find the results when >> you don't rather odd. It's not just old files renamed/deleted in the new >> level that wind up being 'leftover' in the site-packages directory. >> Rather, some files that exist in both levels, and changed between the >> two, are not updated by install. So you wind up with a mixture of >> 0.96.x and 1.0 level files, which is pretty confusing and subject to odd >> failures. >> > > does that apply to PY files, or is it just that you may have PYC files > from 0.96.x but PY files from 1.0? (Python only looks at the timestamp > when deciding whether to recompile a PY file, so if your PYC files for > 0.96.x were created later than the corresponding 1.0 file, Python will > pick up the wrong file). > > is the installer you're referring to here "setup.py", or something else? > > See ticket #9112 for a purported explanation. regards Steve --~--~-~--~~~---~--~~ 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: Install over old level produces mutant [solved!]
Steve Holden wrote: [...] > I've just done an install of 1.0 on my Python 2.6 alpha2 distribution > and I see, for example, that .../django/views/static.py is dated > 12/17/2007. In this case there wasn't a previous installation, so I > can't verify that the compilation won't take place if there's an > existing .pyc file. However I *did* verify that a clean re-install > (after deletion of the appropriate build subdirectories) did *not* > change the creation time of the .py file. Sorry, that should have been ".pyc file". > regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: Install over old level produces mutant [solved!]
Karen Tracey wrote: > We've had at least three people run into a problem (#9090) after > installing 1.0 over an old level. Now, we do document that before > installing you should remove any old level. But I find the results > when you don't rather odd. It's not just old files renamed/deleted in > the new level that wind up being 'leftover' in the site-packages > directory. Rather, some files that exist in both levels, and changed > between the two, are not updated by install. So you wind up with a > mixture of 0.96.x and 1.0 level files, which is pretty confusing and > subject to odd failures. > > Does anyone know if there is something we could do to prevent this > situation? I'm not very familiar with Python installation > procedures. It seems like it would be better, though, if our > installer flat-out refused to install over a pre-existing installation > or offered to delete the pre-existing install before continuing with > the new install. What's the norm for Python packages? > > Karen > I suspect what's happening is that the install keeps the distribution dates on the .py files, but that the people who see the problems have installed (or at least recompiled) the older versions more recently, so the interpreter doesn't require an overwrite of the 0.96 files. I've just done an install of 1.0 on my Python 2.6 alpha2 distribution and I see, for example, that .../django/views/static.py is dated 12/17/2007. In this case there wasn't a previous installation, so I can't verify that the compilation won't take place if there's an existing .pyc file. However I *did* verify that a clean re-install (after deletion of the appropriate build subdirectories) did *not* change the creation time of the .py file. So the answer is to put another step in the build process that touches all files before bundling them up for distribution. Obviously this is best done outside the version control system. regards Steve --~--~-~--~~~---~--~~ 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: I want a pony: Django Cheeseshop
Martin Diers wrote: > On Sep 13, 2008, at 7:23 PM, Russell Keith-Magee wrote: > > >> On Sun, Sep 14, 2008 at 6:35 AM, Martin Diers <[EMAIL PROTECTED]> wrote: >> >>> The answer is community packaging guidelines. Somebody needs to write >>> or adapt an existing doc on how to package django apps using existing >>> Python tools (which are excellent already), how to name them, etc. >>> >> Somebody really is a great guy. He does a lot of great work for the >> community, doesn't he :-) >> >> If you think this document is required, why not write it? Don't wait >> for permission - just write it! >> >> Of course, if you actually sat down to write this document, you would >> rapidly discover why it hasn't been written - the questions you need >> to answer haven't got canonical answers yet. Are you familiar with the >> Django Hotclub? This project started out to answer exactly these >> questions, and they still don't have canonical answers. Pinax is an >> attempt to discover best practices through empirical means, but they >> don't have a complete set of answers. >> >> Yours, >> Russ Magee %-) >> > > > Look, that's exactly my point. Authorship aside, just throwing up a > platform for submitting packages accomplishes nothing without > packaging guidelines. Besides, we already have that. It's called > Google Code. > > Pinax provides a model perhaps for the manner of packaging a project, > but as a whole is more cathedral than bazar. Is it the answer? I don't > know. > > I don't know because I am not qualified to write such guidelines. I > have not been using Django long enough to understand all its parts > well enough, nor to propose how others should work. But I sure as hell > don't want to see yet another repository canonized before the footwork > is complete. Thus here's my vote: No. > Just to return to the original theme, I've been in touch with Richard Jones, Pypi's (the Cheeseshop's) maintainer. He points out that there's already a "Frameworks :: Django" Trove discriminator available, and suggests that if Django developers have a need to change the code (though I am not sure why they would) that too would be possible. The only proviso to that is that the existing web APIs used by distutils and setuptools need to be retained. If they weren't, of course, it would kind of nullify the point of using PyPi in the first place. regards Steve --~--~-~--~~~---~--~~ 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: I want a pony: Distributed RCS
Jacob Kaplan-Moss wrote: [...] > > So, again, sorry about being a dick! > Well at least you're a dick with a proper sense of proportion and the ability to apologize when necessary. Thanks for setting a good example. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: I want a pony: Distributed RCS
ew ways of > doing things, and re-examining philosophies that are followed. That is > how I became a linux user, and a Python programmer. That is why I > started using Django. I was investigating a new way of doing things, and > found that Django had something good to offer. Here I'm just presenting > an alternate philosophy, and hoping for discussion to take place. I > believe that embracing the distributed RCS philosophy will help nurture > the development of Django in the long run. > > Basically, what I'm really trying to say is that there is no pony yet. > There is only a really big pig with a fake pony tail tied onto it, > wearing a saddle. Very ugly. Very Scary. Close your eyes. Little girls > are screaming. > Well, speaking as an old fart, and something of a stick-in-the-mud, I am interested in using the best possible version control system, but even more interested in something that's easy to use. When you consider attracting new members to the development community, ease of use of the development infrastructure is important. I've heard good things about Mercurial, Bazaar and git, but I get the impression that git is sometimes difficult to drive. Overall the idea of a distributed version control system is great. But will I be able to drive it without getting myself in a mess? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: I want a pony: Django Cheeseshop
mrts wrote: > On Sep 10, 7:12 pm, "Eric Holscher" <[EMAIL PROTECTED]> wrote: > >> your django apps. There is no reason to reinvent the wheel here, especially >> after what Mark talked about at Djangocon (Django being considered seperate >> from the Python community). >> > > Although I don't know anything about the talk, that's exactly what I > wanted to say: as Django and Python communities are different, > overflooding CheeseShop with Django apps does not serve Python > community at all. > > And I never had re-implementing setuptools in mind -- what I meant was > to extend and build upon setuptools and easy_install. > I don't see why Django can't be just as much a part of the Python community as, say, Zope, who frequently distribute code through PyPi. I don't see the advantage of fragmenting the infrastructure. That's what it's there for - supporting Python users. regards Steve [PSF chairman] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
App label for NFA
Please forgive me if this feature exists and I have overlooked it. Does anyone else think it would be desirable and useful to allow for overriding the default app-labels in NFA? By this I mean the headers which the ModelAdmin's fall under. I've got a situation where I have a 'core' project which serves several offices, however, each office has a few '*app_name*_local' addendum models which compliment the core. To my client offices, there is no reason for distinction between them in NFA. Now, of course I can simply import the core admin.py and then register it at the local level, however, I'm still stuck with an uncorrect _local app-label. -Yeago --~--~-~--~~~---~--~~ 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: Mentoring students
Chris De Vries wrote: > Hi, > > My name is Chris De Vries and I am involved with the IEEE student > branch at the Queensland University of Technology in Brisbane, > Australia [1]. I am organizing a program that encourages students to > become involved with open source. I am looking for projects that are > interested in taking on students. The branch will be running an > information session and I am hoping to list some projects that are > willing to mentor students. Is Django interested? > > Thanks, > Chris De Vries > > [1] http://ewh.ieee.org/sb/queensland/qut/ > Chris: Any project that was involved with the Google Summer of Code might well be interested in mentoring student projects. You might also want to ask on the django-users list (if you haven't already), as there may be applications of Django that meet your requirements. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
DjangoCon
Well, since I can't make the conference I hope that everyone who *does* get there has a great time! regards Steve --~--~-~--~~~---~--~~ 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: Session expiration times
TP wrote: > I recently ran into what I thought was counter-intuitive session > expiration behavior. See ticket http://code.djangoproject.com/ticket/8452 > for the details. > > I don't mean to dig up topics that have been long debated, but I also > wonder if these semantics make sense? > > If I log into a site and only happen to read from my session, my > session will log out in SESSION_COOKIE_AGE seconds (or whatever > set_expiry says). However, if I happen to do actions that cause writes > to my session then my session will expire in some hard-to-determine > point in the future. How to explain to a user when they will be logged > out -- X seconds after their last session write? I wrote the app and > I'm not even sure when the session is written to due to third party > libraries etc. > > Further, for security reasons it seems like it's a good policy for > Django to ship with the default behavior for every session to > automatically expire SESSION_COOKIE_AGE seconds after the session was > created no matter what. If the app wants to push out the expiration > time every time the user is active, they can call set_expiry > explicitly. But I guess that's just one person's opinion. > > Alternatively, for consistency, Django could update the expiry age > whenever the session is _read_ or written. Then the docs could simply > say the expiry age is updated whenever the session is used which is > very simple to understand: anytime someone comes back to the site > their session expiration time will renew. If they don't come back > within the expiration time, their session expires. SESSION_SAVE_EVERY_REQUEST is by far the most sensible option, and the default behavior for every other web framework I've used. Interaction of any kind with the server should be taken as an indication that the session user wants the session to remain alive. At least it's documented, though ... regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: Is URL template tag's syntax going to change?
Johannes Dollinger wrote: [...] > Of course that's subjective, everything is. > Really? That's a bit sweeping. "The atomic number of hydrogen is 1" (IMHO?). regards Steve Who just felt like picking this particular nit. Sorry. -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: ~Q broken?
Malcolm Tredinnick wrote: > > On Wed, 2008-07-16 at 10:12 -0700, serbaut wrote: >> Consider the following equivalent queries based on the weblog model >> from the documentation: >> >> Blog.objects.filter(name="myblog").exclude(entry__body_text__contains="blah >> blah") >> Blog.objects.filter(Q(name="myblog") & >> QNot(Q(entry__body_text__contains="blah blah"))) # 0.96 >> Blog.objects.filter(Q(name="myblog") & >> ~Q(entry__body_text__contains="blah blah")) # development version >> >> In 0.96 the evaluated SQL is (edited for readability): >> >> SELECT blog_blog.id,blog_blog.name,blog_blog.tagline >> FROM blog_blog >> INNER JOIN blog_entry AS blog_blog__entry ON blog_blog.id = >> blog_blog__entry.blog_id >> WHERE blog_blog.name = "myblog" >> AND (NOT (blog_blog__entry.body_text LIKE "%blah blah%")) >> >> while in trunk (r7982) it is >> >> SELECT blog_blog.id, blog_blog.name, blog_blog.tagline >> FROM blog_blog >> WHERE blog_blog.name = "myblog" >> AND (NOT (blog_blog.id IN (SELECT blog_entry.blog_id FROM blog_entry >> WHERE blog_entry.body_text LIKE "%blah blah%"))) >> >> The trunk version will perform a subquery over all blog entries which >> will have a very negative performance impact. >> >> Lets say "myblog" has 10 entries in a database with 10,000,000 >> entries, the first SQL will only examine the 10 entries (assuming >> decent query planner) while the latter will scan the whole database. A >> join with blog_blog.id is missing from the subquery or it needs to be >> rewritten to the 0.96 form. I understand that the code tries to handle >> the generic case but this practical case has to work too. > > The important difference, that trumps everything else, is that the 0.96 > version gives the wrong answer! It isn't a case of less or more > efficient -- it's the difference between correct and incorrect. > > The query you described asks to exclude all blog entries containing a > particular tag. Now consider a blog entry that has two entries. One is > the entry you're interested in excluding and the second entry is > something else. Because that blog has an row in the m2m join table that > does not match the entry you are excluding, that blog will be included > (incorrectly) in the result set. This was a very big bug in 0.96 and > impossible to work around in that code. > > There is no way to write that particular exclusion correctly without > using nested subqueries unless you have some arbitrary constraint like > only one tag per blog entry (in which case a many-to-many field is the > wrong choice). > > Remember that the query you are writing here is something that returns > (and filters) Blog objects. It's not for excluding individual Entry > objects. It uses the presence or absence of an Entry to filter the > Blogs. > > Your case is particularly pessimal, since it isn't going to be helped by > index matches in most cases. For more natural uses, such as excluding by > pk values, or whole-field matches, adding appropriate index comparisons > makes the inner query very efficient if it becomes a performance issue > in production environments. > Note that there's nothing wring in the general case with nested subqueries. The problem arises with what are called "correlated subqueries", where an element of the rows from the outer query is used in the sub-query. In other words, given an employee table where each employee has a manager, it's quite fast to work out who earns more than a specific employee: SELECT * FROM employee WHERE salary > ( SELECT salary FROM employee WHERE ID=1234) The subquery returns a result that's invariant over the rows of the outer query, and most SQL implementations will only perform it the once. It's quite a different story if you want to find out who earns more than their manager, however: SELECT * FROM employee AS sub WHERE salary > ( SELECT salary FROM employee AS mgr WHERE sub.salary > mgr.salary) In such cases the SQL optimizer usually has little choice but to repeat the subquery for each row in the outer query, which can get a little expensive. Then later said: > The problem is that the filter you specified was not returning the > correct answer in 0.96. You're asking that Django returns an incorrect > result to make your code faster. It's possible to give incorrect results > very fast, but it's not something we want to support. Which made me laugh :-) Sorry if this is preaching to the choir: sometimes people assume that *all* nested
Re: Declarative syntax for widgets in ModelForm
Ivan Sagalaev wrote:
> Hi, everyone!
>
> I was recently refactoring some old code to use a ModelForm and was
> stuck at an issue that we don't have a simple way to say "this form has
> these fields from a model but with other widgets".
>
> For example I have an Article model that I want to edit in a form:
>
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
>
> This is nice! But now I want to use a bit larger textarea for 'text' and
> want specify it with attrs={'cols': 80, 'rows': 20}. Currently I have
> two options:
>
> 1. Redeclare entire field:
>
> class ArticleForm(ModelForm):
> text = CharField(
> u'Text',
> is_required=True,
> widget=Textarea(...))
>
> class Meta:
> model = Article
> fields = ['author']
>
> The problem is that along with a widget I have to repeat other
> attributes of a field: type, label, required-ness, help_text etc...
> Which is bad because it's, ahem, "non DRY" :-). It's also looks a bit
> strange because now fields are declared in two different ways.
>
> 2. Fix widget in __init__:
>
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
>
> def __init__(self, *args, **kwargs):
> super(ArticleForm, self).__init__(*args, **kwargs)
> self.fields['text'].widget = Textarea(...)
>
> Here the problem is that it has enough boilerplate code to be, shall we
> say, not beautiful. And also it defeats nice declarative nature of a
> ModelForm.
>
> In other words the problem of ModelForm is that we have very usefule
> separation between fields and widgets but we cannot declare them separately.
>
>
> ## Proposal
>
> To fix this I was thinking along the lines of:
>
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
> widgets = {
> 'text': Textarea(...),
> }
>
> I know it can be done now with formfieldcallback but it doesn't look
> nearly as readable because you have to write an imperative logic
> comparing field names.
>
> Sound sane?
>
What's CSS for?
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
--~--~-~--~~~---~--~~
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: Community representation, or, #django user "Magus-" needs to go far away
Eric wrote: > Well, you can teach someone to fish without telling them to "get an > f'n fishing pole". > > "Give a man a fish and he will eat for a day. Teach him how to fish and for the rest of his life he will bore you with stories about the one that got away". regards Steve --~--~-~--~~~---~--~~ 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: Spam detection
Rob van der Linde wrote: > I see there is now a link to the registration page when you go to file a > ticket, but why not put it on page where the login/settings links are > (just underneath the search box). This is where it is by default in Trac > and people might expect to see it there, like I did myself initially. ... and why not have it say "Your post *will* be rejected as spam unless you are registered and logged in"? At the moment it sounds like you *might* get away with an unregistered posting. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: Community representation
Russell Keith-Magee wrote: > On Tue, Jul 1, 2008 at 5:25 PM, Kenneth Gonsalves > <[EMAIL PROTECTED]> wrote: >> Let him be as rude as he wants, as long as he is there. > > Lets stop this idea before it grows legs. One of the strengths of > Django is the community, and one of the reasons the community is > strong is because it is approachable for newcomers. > > There's no problem with being blunt or brusque, but straight out > rudeness is not appropriate, and it will not be tolerated. > In which case perhaps a change of subject line might be appropriate? I would say that Magus *is* blunt or brusque rather than rude. His approach isn't always appreciated because he won't "spoon-feed" people, preferring instead to lead them by the hand (or, occasionally, a rather more tender body part). But that's going to make for a more capable community in the end, and is better from a learning point of view. Besides which, sometimes it's amusing to watch the conversations. We are a long way from the c.l.perl flaming of newbies. People are definitely getting the answers they need, and Magus is a prime distributor of high-quality information to the IRC channel. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: Spam detection
Jacob Kaplan-Moss wrote: > On Thu, Jun 26, 2008 at 1:06 PM, Andreas Klöckner > <[EMAIL PROTECTED]> wrote: > >> I tried to submit this bug, but it wouldn't let me--it thought I'm a spammer. >> > > Quoting from the ticket submission page: > > "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." > > OK, a 500 error isn't really appropriate anyway, surely: the submission is being rejected due to lack of authentication, presumably this is supposed to mislead spammers? Why not begin the message with: "Did you register an account and log in before submitting your issue? Non-registration is the most common cause of this error. Please click here to register an account before submitting this issue." Or something similar. regards Steve > The version on that page even has links. > > Help me out here: how can I make it more obvious? You missed that; > others often do to. Can you share with me some insights on how you > missed it? > > 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: Errors in django/tests/regressiontests/views/fixtures/testdata.json?
Russell Keith-Magee wrote: > On Thu, Jun 19, 2008 at 9:04 PM, Peter Melvyn <[EMAIL PROTECTED]> wrote: > >> On 6/19/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: >> >> >>> (2) provide a way to manually disable and re-enable integrity checks. If >>> someone with more MySQL-fu than me knows how to do either of these >>> >> It should work: >> >> SET FOREIGN_KEY_CHECKS = 0; >> > > Yes - the ticket for this problem (#3615) already has a patch that > uses this technique. > > However, I was under the impression that this has the effect of > disabling, not just deferring key checks - that is, if you disable > checks, load bad data, then re-enable checks, no errors will be > raised. We don't want to be responsible for breaking the referential > integrity of a database, so this isn't a viable solution. > > If I've misunderstood the behaviour of SET FOREIGN_KEY_CHECKS, or you > have any other suggestions, let me know - I'd very much like to put > this bug behind us. > Well I guess the obvious (time consuming, painful) way would be to validate the semantic integrity from Django in the back end. That could, if automated, get horrendously time-consuming for even quite small changes to the database. Would there be any way to analyze which constraints could be affected by the SQL executed while checks were disabled, so automated checks could be limited to those? Otherwise I'd guess you end up saying "Tough, MySQL is currently broken/less capable". Maybe we could talk to Ted Leung about that? regards Steve --~--~-~--~~~---~--~~ 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: Bug that cannot be reproduced
On Jun 15, 2:08 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Sun, Jun 15, 2008 at 2:43 PM, Steve Potter <[EMAIL PROTECTED]> wrote: > > > I recently ran across a bug in Django and was pointed to ticket #7199 > > that described the same problem. It turns out that 7199 is a > > duplicate of #7155 which as a working patch. > > In which case, you should close #7199 as a duplicate, noting that it > is a duplicate of #7155. > It has already been closed. > > > > However, in my research of this problem (as noted in 7199) I found > > another potential bug. > > In django/db/models/sql/subqueries.py on line 357: > > > date = typecast_timestamp(str(date)) > > > If the date is NULL the typecast_timestamp will return a a ValueError > > because the string representation of NULL 'None' cannot be cast to an > > integer. > > > So the problem is I can see the potential for this bug, but it only > > shows it self due to another bug. I don't know any other way of re- > > producing it. > > Do I open a ticket and submit a patch (for which I have no idea how to > > make a test case)? > > or > > Do I just leave it alone as if everything else is working properly, it > > may never reveal itself again? > > I'm a little confused about exactly what you have found, but in > general terms, if you have found a bug, please open a ticket. Provide > as much detail as you can to help someone else reproduce the same > error condition. This includes any 'prerequisite' bugs: if the > presence of #7155 masks the emergence of your new bug, then mention in > the report that "this only occurs when bug #7155 has been fixed; patch > ABC fixes that bug". This situation is a bit odd. This bug only show itself when 7155 has not been patched. However, the patch for 7155 in no way changes this code. It appears to be code that has been present in django and working fine for quite some time. It is simply situation where if date == NULL then the line date = typecast_timestamp(str(date)) will produce an uncaught exception. However it the only case I know if where date will be NULL at this point in the code is if the bug in ticket 7155 is not patched. (However it is possible that there are other cases that I don't know about) Thanks, Steve --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Bug that cannot be reproduced
I recently ran across a bug in Django and was pointed to ticket #7199 that described the same problem. It turns out that 7199 is a duplicate of #7155 which as a working patch. However, in my research of this problem (as noted in 7199) I found another potential bug. In django/db/models/sql/subqueries.py on line 357: date = typecast_timestamp(str(date)) If the date is NULL the typecast_timestamp will return a a ValueError because the string representation of NULL 'None' cannot be cast to an integer. So the problem is I can see the potential for this bug, but it only shows it self due to another bug. I don't know any other way of re- producing it. Do I open a ticket and submit a patch (for which I have no idea how to make a test case)? or Do I just leave it alone as if everything else is working properly, it may never reveal itself again? Thanks, Steve --~--~-~--~~~---~--~~ 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: extra() and values()
Nicolas Lara wrote: > The ticket is in the tracking sistem: #7256. I have claimed it, but am > not planning to start working on it until I'm done with aggregation > (or maybe in EuroPython's sprint), so if anybody bits me to it, it > would be great. > > In that case you would be better off leaving it unclaimed until you are ready to work on it. Moset people look for unassigned tickets when they have bug fixing time, to avoid repetition of work. regards Steve --~--~-~--~~~---~--~~ 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: range in templates?
Mark wrote:
> I'm new to django so I apologize if after reading through the docs and
> list I missed something obvious. I would like to do something like
> this in a template:
>
> {% for index in range(10) %}
>
> but I can't seem to find anything that will allow this. I've become
> used to the idea that when something that should be easy seems hard I
> am usually going about it the wrong way, but in this case I'm pretty
> certain this logic belongs in the template. I've got space for 15
> image thumbnails, but when I only have say 5 thumbnails I want to fill
> the space with a standard filler thumbnail for purely aesthetic
> reasons.
>
> The only alternative I can think of is to make an arbitrary list of
> the correct length in my view and pass it to the template, but this
> seems silly.
>
> What am I missing?
>
Well, the first thing you are missing is that the django-dev list is to
discuss development *of* Django rather than development *with* Django.
You want django-users, just down the corridor :-)
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
--~--~-~--~~~---~--~~
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: Subversion Access
Rahein: Please also note that you are supposed to adjust your path so svn is runnable from anywhere, not run svn in its bin subdirectory. Google for "set path" followed by your operating system name if you don't know how to do this. regards Steve Dan Watson wrote: > Questions like this should be directed to the django-users mailing > list. > > That said, this is probably caused by your proxy server not > understanding how to handle subversion's requests. See > http://subversion.tigris.org/faq.html#proxy or search the mailing > lists - this has come up before. > > On May 7, 5:00 pm, Rahein <[EMAIL PROTECTED]> wrote: >> I am trying to get the Django Trunk downloaded and this is my first >> excursion into using Subversion. >> >> I followed the directions in the installing guide, but when I run the >> command in subversion's bin folder: >> >> svn cohttp://code.djangoproject.com/svn/django/trunk/django-trunk >> >> I get these error message: >> >> svn: REPORT request failed on '/svn/!svn/vcc/default' >> svn: REPORT of '/svn/!svn/vcc/default': 400 Bad Request (http:// >> code.djangoproject.com) >> -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Want to have unit tests in multiple files
Hi, we're just getting started using Django unit tests, and it looks like the documentation says you can only have unit tests in two files: models.py and tests.py. We would prefer to put our unit tests in many different files, with, say, each main-line .py file having a corresponding unit-test file. Is there a convenient way to do this in Django? --~--~-~--~~~---~--~~ 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: Lock-In
In fact this question would be better addressed to a more general list, such as the comp.lang.python newsgroup (also available as [EMAIL PROTECTED]). See http://mail.python.org/mailman/listinfo/python-list for further information. regards Steve [EMAIL PROTECTED] wrote: > django-developers is meant for questions regarding the development of > django itself, questions about the usage of django should be directed > to django-users. > > On May 4, 1:27 am, Kamal <[EMAIL PROTECTED]> wrote: >> Question, >> >> I work in a company that is adopting the agile method, scrum. They are >> doing implementing it using c#, which I think is funny. How does a >> company decide to switch its development language? We have very long >> development cycle's, and I would have thought they would have looked >> at the language they are using, but they laugh when that is suggested. >> >> Has anyone seen a company pull off a switch from a .Net / Sql based >> environment to a Python / MySql sucefully? Where benifits seen? > > > -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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 port on OpenVMS - Oracle/Rdb backend
Don Spaulding II wrote: > > > Collin Grady wrote: >> Steve Holden said the following: >> >>> If you want considered opinions you would do well to wait longer than 51 >>> minutes! >>> >> >> You should check the date as well as the time; he sent the first email >> *two days* before the second. >> > Steve, perhaps next year at pycon we could have a "Teach Me Google" BoF? > Or a "Teach Me Common Sense"? So, now we've established I'm a bozo, will someone please answer his question! regards Steve PS: Completely off-topic apart from the "Teach Me Google", can anyone tell me why Google Groups/Gmail isn't sending me my own messages? -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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 port on OpenVMS - Oracle/Rdb backend
Jean-François wrote: > Any comment, especially on the transaction model? If you want considered opinions you would do well to wait longer than 51 minutes! regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: API question for model saving
Malcolm Tredinnick wrote: > Hey David, > > On Mon, 2008-04-28 at 12:21 +0200, David Larlet wrote: > [...] > >> def save(self): >> if not self.id: >> self.some_date = datetime.now() >> super(Model, self).save() >> >> to: >> >> def create(self): >> self.some_date = datetime.now() >> super(Model, self).create() >> > > For this particular case it saves a whole line. One concern I have is > that if there's more complex logic in your overridden save method, some > of it is going to be useful in both cases and now you have to create > extra sub-functions for the common bits and remember to call them both > times. It leads to duplication. If you look around at sample code on > django-users and other places, you can see people doing a number of > pieces of auxilliary processing as a result of save happening on the > instance, so this isn't a trivial issue. > > >> BTW, create()/update() sounds more explicit to me than save(). >> > > Which immediately leads to one of the problems with it. Suppose I'm > writing a function that accepts objects, does something to them and then > wants to save them. Do I call create() or update()? There's no way to > tell. Currently, I call save() with no ambiguity problem. > > I s'pose that's the killer to the separate-methods argument. > Also, this presents an unnecessary backwards-incompatibility. Every > single piece of code now has to change to use one or other of these > methods. Every save() call. Currently and with the parameter approach, > *zero* existing code has to change initially. If you want to support the > must insert vs. must update difference, you can add a parameter (or two, > depending on which approach we take) and it's still backwards > compatible. > How do these parameters get set for the above "function that accepts objects and wants to save them"? Presumably it too has a default "must_create"? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: API question for model saving
David Larlet wrote:
> Le 28 avr. 08 à 09:33, David Danier a écrit :
>
>
>>> Sometimes when calling save(), we know (for business reasons) that it
>>> must create a new object or raise an error. Similarly, in other
>>> cases,
>>> it either must update an existing object or raise an error.
>>>
>> I think discussion about this issue has been on this list before, last
>> time someone suggested adding create() and update()...and keeping
>> save()
>> as an method calling these two, like:
>> -8<
>> class Model(...):
>> def save(self, ...):
>> if self.has_pk() and self.pk_exists():
>> self.update()
>> else:
>> self.create()
>> def update(): ...
>> def create(): ...
>> >8-
>>
>> So what is the big advantage of having an new parameter in save() like
>> you suggested? With having create()/update() you can do similar
>> things.
>>
>> Additionally it would be possible to override only parts of the
>> save()-logic in classes extending Model (for example when needing to
>> calculate field-values on create, but not on insert...which is
>> currently
>> difficult).
>>
>> And, of course, you would have no problems with naming the new
>> parameter
>> and difficulties in creating self-explaining possible values ("not
>> must_create", rather than "must_not_create").
>>
>
> I'm +1 on this solution, which turns the well known pattern:
>
> def save(self):
> if not self.id:
> self.some_date = datetime.now()
> super(Model, self).save()
>
> to:
>
> def create(self):
> self.some_date = datetime.now()
> super(Model, self).create()
>
> BTW, create()/update() sounds more explicit to me than save().
>
You could argue that the separate-method solution has better cohesion.
Malcolm's point that this is very much a minority use-case, and that
mostly the two methods will anyway simply call a modified save with
alternative values of the flag (whose names are a little smelly, by the
way) is reasonable, I suppose.
But it does seem to me that create() and update() are more explicit than
save(must_create=True) and/or save(must_update=True). The separate
method solution also removes the possibility of the illegal fourth case
(must_update==must_create==True), which means there would be no need to
test for it.
In summary, we are arguing around the ragged edges of an overall very
neat system.
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
--~--~-~--~~~---~--~~
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: SVN Milestones
Kenneth Gonsalves wrote: > On 20-Apr-08, at 12:47 AM, Steve Holden wrote: > >>> I wouldn't even call the current svn head a beta-quality product >>> >>> >> Which is probably why it isn't yet a beta release? >> > > what I meant is that it is stable and production ready and that it is > time people stopped evaluating products by looking at the version > numbers > Stable and production-ready until the new functionality that's due "real soon now" comes in. I don't think it's unreasonable of people to wait until there is an announcement of future stability, which is effectively what 1.0 will represent. At the moment I would agree that (even) more people could probably use the trunk version for production systems, but it's human nature for some people to crave stability and want to avoid changing code to keep in step with current versions, so they stay away from Django because they know that /something/ is due to change, though they may not know the details of newforms admin or queryset refactoring. We can probably agree that the sooner 1.0 comes out the better it will be for Django takeup, but that doesn't mean a compromise on quality is acceptable. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: SVN Milestones
Kenneth Gonsalves wrote: > On 19-Apr-08, at 8:52 PM, James Bennett wrote: > > >> On Sat, Apr 19, 2008 at 10:17 AM, ydjango <[EMAIL PROTECTED]> >> wrote: >> >>> Is there a reason you cannot call it just 1.0 >>> >> So would you prefer to have a beta-quality product whose developers >> lie and call it 1.0? >> > > I wouldn't even call the current svn head a beta-quality product > > Which is probably why it isn't yet a beta release? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: floating point django.VERSION element versus adding another element to the tuple
J. Cliff Dyer wrote: > As you said, it's a bikeshed argument, so I'm not going to push hard on > this, but I do want to put one thing out for discussion. There is some > value in making versions increase in sort order, so you can do "if > django.VERSION > target:". If 'final' were changed to 'release', this > would work. 'beta' < 'rc' < 'release' < 'svn'. > > Just a thought. > > And to throw a wrench into everything, including my own thought, what > would branch versions look like in your scheme? > > Cheers, > Cliff > > > On Fri, 2008-04-18 at 12:46 -0500, James Bennett wrote: > >> And because lately we've been doing various specification-type things, >> I'd like to propose (with release manager hat firmly planted on my >> head) that going forward we do things in the following fashion. >> >> >> Format of ``django.VERSION`` >> >> >> ``django.VERSION`` is a 3-tuple, of the form:: >> >> (major-version, minor-version, modifier) >> >> >> Packaged releases >> = >> >> In a packaged release, the elements of the ``django.VERSION`` tuple >> are: >> >> 1. The major version tree from which the release is packaged. >> >> 2. The minor version the package represents. >> >> 3. A modifier indicating the release status of the package. >> >> The modifier may take any one of the following four forms: >> >> 1. 'beta'; this is a beta leading up to a final release, and '' >>represents the number of the beta release; the first beta for 1.0, >>for example, would be (1, 0, 'beta1'), the second beta for 1.0 >>would be (1, 0, 'beta2'), etc. >> >> 2. 'rc'; this is a release candidate leading up to a final release, >>and '' represents the number of the release candidate; the first >>release candidate for 1.0, for example, would be (1, 0, 'rc1'), the >>second release candidate for 1.0 would be (1, 0, 'rc2'), etc. >> >> 3. 'final'; this is the packaged release of a specific version of >>Django, and represents a stable, tested version to which the Django >>project commits support per the support/security policy. Django 1.0 >>would, for example, be (1, 0, 'final'), Django 1.1 would be (1, 1, >>'final'), etc. >> >> 4. 'p'; this is a bugfix and/or security release for a prior >>version of Django, released in accordance with the support/security >>policy. The first such release for Django 1.0 would be (1, 0, >>'p1'), the second such release for Django 1.0 would be (1, 0, >>'p2'), etc. >> >> >> SVN checkouts >> = >> >> For an SVN checkout, the elements of the ``django.VERSION`` tuple are: >> >> 1. The most recent major version released at the time of the specific >>SVN revision being checked out. >> >> 2. The most recent minor version released at the time of the specific >>SVN revision being checked out. >> >> 3. The modifier 'svn', indicating an SVN checkout, where '' is >>the revision of the checkout from the repository. >> >> So, for example, if you do an SVN checkout of revision 31337 and, at >> the time of that revision, the most recent major version was 3 and the >> most recent minor version was 14, then VERSION in your checkout will >> be:: >> >> (3, 14, 'svn31337') >> >> >> Why this is a good thing >> >> >> How to do the version tuple is mostly a bikeshed argument. Ultimately, >> three things matter in deciding how to handle it: >> >> 1. The BDFLs/core dev team are OK with it. >> >> 2. The system used is consistent. >> >> 3. The system used is easy to parse into human-readable formats. >> >> The above system meets (2) and (3) -- it offers a version tuple in a >> consistent format, and one which is easy to turn into a human-readable >> string like "Django 3.2", "Django 1.4-beta3" or "Django >> 2.18-svn28183". >> >> The only question is whether it meets (1). Thoug Without wishing to turn this into a long-drawn-out discussion, why be willfully different from Python itself? From 2.0 on there's been a standard of sorts in sys.version_info: """*version_info* A tuple containin
Help with getting drop-downs to work
Trying to get admin on my system to load values based on related
tables on db. I have set the FK on the papers table to tie with the
PK of each look-up table and set models like so:
class LuPaperContentEra(models.Model):
paper_content_era = models.CharField(blank=True, maxlength=150)
def __unicode__(self):
return self.paper_content_era
class Meta:
db_table='lu_paper_content_era'
The main table, which should contain drop-downs for things like the
model/table above, has things like:
class Paper(models.Model):
... many fields defined
PaperContent_Era = models.ForeignKey(LuPaperContentEra)
... more fields defined
class Meta:
db_table='papers_admin'
class Admin:
list_display=('id','FirstName','LastName','Institution')
search_fields=['LastName']
However, Admin displays the drop-down as
LuPaperContactEra object, NOT the actual human-readable value list.
I feel I am probably close to getting this to work but can't seem to
find the right direction in which to be "nudged".
Thanks!
--~--~-~--~~~---~--~~
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: Opportunity
Sorry I am new to this - what do you mean? Steve Brumwell Sales Director www.iperium-consulting.com (P) +44(0)1564 793701 (M) +44(0)7810 801130 (F) +44(0)1564 795916 Skype id : steve.brumwell __ __ Iperium Blog __ OneWorld.Referred. _ * The information contained in this e-mail and attachment (if any) is intended for the person to whom it is addressed and may contain confidential and/or privileged information. The contents of this message may contain personal views, which are not the views of Iperium Consulting Ltd, unless specifically stated. You should not copy, retain, forward or disclose its contents to anyone else, or take any action based upon it, if it is not addressed to you personally. If you have received this e-mail in error please contact the sender immediately. Any legally binding agreement resulting from its content must be made separately in a printed medium. * -Original Message- From: django-developers@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Patryk Zawadzki Sent: 05 March 2008 15:51 To: django-developers@googlegroups.com Subject: Re: Opportunity On Wed, Mar 5, 2008 at 4:37 PM, Steve Brumwell <[EMAIL PROTECTED]> wrote: > Hello all, > > I am currently working on behalf of a strong and well funded start up > in the online media (2.0) space, they are growing fast and very > innovative. They need a senior level Python/Django developer to work > in London. Please contact me for further details. The role is full > time and comes with an attractive salary. 1) move to django-users 2) fix your signature skyscraper 3) remove legal threats -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Opportunity
Hello all, I am currently working on behalf of a strong and well funded start up in the online media (2.0) space, they are growing fast and very innovative. They need a senior level Python/Django developer to work in London. Please contact me for further details. The role is full time and comes with an attractive salary. Steve Brumwell Sales Director www.iperium-consulting.com (P) +44(0)1564 793701 (M) +44(0)7810 801130 (F) +44(0)1564 795916 Skype id : steve.brumwell __ <http://www.iperium-consulting.com/> __ <http://www.brummers72.wordpress.com/> Iperium Blog __ <http://brummers72.files.wordpress.com/2007/08/owr.jpg> <http://brummers72.files.wordpress.com/2007/08/owr.jpg> <http://www.brummers72.wordpress.com/oneworld/> OneWorld.Referred. _ <http://www.linkedin.com/in/stevenbrumwell> * The information contained in this e-mail and attachment (if any) is intended for the person to whom it is addressed and may contain confidential and/or privileged information. The contents of this message may contain personal views, which are not the views of Iperium Consulting Ltd, unless specifically stated. You should not copy, retain, forward or disclose its contents to anyone else, or take any action based upon it, if it is not addressed to you personally. If you have received this e-mail in error please contact the sender immediately. Any legally binding agreement resulting from its content must be made separately in a printed medium. * --~--~-~--~~~---~--~~ 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: please help! need to know python version
On Jul 5, 12:48 pm, anna <[EMAIL PROTECTED]> wrote: > Just in case anyone knows, is it the same with the other frameworks > for Python, like Pylons, Turbogears, etc? I'm thinking yes, based on > your answers here, but just wondering. > As someone coming to Django from TurboGears, I can say that TurboGears tends to develop for one version of Python and then add support for other versions as lesser supported afterthoughts. It was originally developed for Python 2.4. When the topic of 2.3 support came up on the mailing list, the lead developers initial response was "Hasn't everyone upgraded to 2.4?" It now has support for 2.3, but it's really not tier one support, as TG makes such heavy use of decorators. Python 2.5 is now officially supported, but that is a recent development. As I have many clients on CentOS/RHEL, Django's equal treatment of 2.3, 2.4, and 2.5 is *greatly* appreciated. --~--~-~--~~~---~--~~ 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 branch?
On 2007-01-17, Russell Keith-Magee wrote: > > No apologies necessary. I've spent some time in Germany, so I > understand the uniquely German approach to directness ;-) > Unfortunately, it has been my experience that this doesn't always > translate well - I just wanted to make it clear (particularly to those > that are new to the Django community) that the issue here is people > being busy, not people being ignored. It sounds like Jacob is the right one to create the branch. Maybe the best thing is to contact him again directly to remind him? :-) Here's what he wrote last week: >>>Re: Schema Evolution branch? >>>Jacob Kaplan-Moss >>> Mon, 08 Jan 2007 21:15:19 -0800 >>> Crap -- I must have missed that email. I'll get something set up first >>> thing tomorrow morning (my wife's telling me to close the damned laptop >>> and go to bed...); please feel free to poke me again if I forget! >>> Jacob Steve --~--~-~--~~~---~--~~ 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: Should Django be HTML agnostic?
On 2007-01-11, Rob Hudson wrote: > > 2. The argument against #1 that I've seen is usually that you can > subclass Something and write your own output. But in some ways, this > violates the DRY principle. The code to output a form widget, for > example, is already written, and in looking at what it would take, the > only change in the render() method would be the change of the HTML > itself. > > 3. Better "updatability": If there is a bug in Select(Widget) that was > fixed but I have MySelect(Widget) which is mostly the same except for > the HTML, I wouldn't get the fix unless I noticed and updated my code > as well. Whereas if Select(Widget) pulled in a template and I overrode > that template, the fix would come down just fine across all my > projects. Yes, in more general terms, this design violates the Single Responsibility Principle [1]; the method designed to be overridden has more than one reason to change: framework driven fixes/enhancements, and user level changes to the details of the presentation (e.g. markup type) Conveniently, templatizing the markup is a readily available design alternative which cleanly separates the responsiblities. > 4. One of the reasons I've seen touted for the template system not > having access to Python methods and having it's own language is the > benefit of separating the programmer from the designer and that > designers shouldn't need to know Python to create templates in Django. > But they would if they want to manipulate forms or form error feedback. > This should be consistent. I think this point also has significant merit. Steve [1] http://en.wikipedia.org/wiki/Single_responsibility_principle --~--~-~--~~~---~--~~ 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 branch?
On 2006-12-28, David Anderson <[EMAIL PROTECTED]> wrote: > > Hey all, > > I've been hacking on my application for a bit now, and I'm at the > point where I'd want to be able to evolve my schema, rather than blow > away the data or futz around with SQL to upgrade stuff. So I took a > look at the schema-evolution branch, and it looks mostly abandoned. > > Is this the case? Is the code there still desired in general for > Django? If so, and if nobody is actively working to get it running, > how can I help to get this branch back on its feet and polished? There have been some recent discussions about this on the users list. The SOC branch is apparently not being maintained, but Victor Ng has an alternative implmentation. He has asked for a new branch to be opened so those who want to test and develop this new code base can more easily collaborate. http://groups-beta.google.com/group/django-users/browse_thread/thread/bd1417a08e37774a/67af32e775dae595 Steve --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
schema-evolution branch - docs and status?
Hi, where can I find user and developer docs describing the schema evolution suport? Any status update? Still awaiting user feedback? The code browser seems to indicate features from the trunk aren't getting backported into this branch... http://code.djangoproject.com/browser/django/branches/schema-evolution Thanks, Steve --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
IOError: Client read error (Timeout?)
Hi, guys. This is a problem that troubled me for months, but maybe it is very easy to you. I guess it is an problem that has something relation with mod-python or cookie, but I am not sure. Since many corresponding softwares I use, between our production and develope server, are the same except Linux/Debian version. But on production server, SOMETIMES this error will be encountered, while on develop server, this error NEVER happens. The behavior that cause this error is an ajax call, that will generate some HTML elements on the pages. Simply to say, it is something like, when I click a button in the page, there will be some TABLES added to the current page. Then comes the problem, sometimes it works, sometimes, it fails when I am using IE. But in firefox, it is always okay. The following are the error log get from django: Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/django/core/handlers/base.py", line 113, in get_response request_repr = repr(request) File "/usr/lib/python2.3/site-packages/django/core/handlers/modpython.py", line 16, in __repr__ return '' % \ File "/usr/lib/python2.3/site-packages/django/core/handlers/modpython.py", line 45, in _get_post self._load_post_and_files() File "/usr/lib/python2.3/site-packages/django/core/handlers/modpython.py", line 28, in _load_post_and_files self._post, self._files = httpwrappers.QueryDict(self.raw_post_data), datastructures.MultiValueDict() File "/usr/lib/python2.3/site-packages/django/core/handlers/modpython.py", line 95, in _get_raw_post_data self._raw_post_data = self._req.read() IOError: Client read error (Timeout?) Request repr() unavailable software version I am using Apache2 : 2.0.55-4 Mod-pyton: 3.1.3-3 Django: 0.91 r2509 Linux/Debian: 2.6.12.2, error happenes at this server, which is our production server Linux/Debian: 2.6.8.1, this one works fine, which is our development server Browser: IE 6.0 sp2 Any suggestions will be appreicated. Thanks. BR~ ChengQi --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
