Re: template or is it template_name
On Wed, Nov 11, 2009 at 5:06 AM, Sean Brant wrote: > > Stop me if you have heard this one before. Anyone else find it > annoying that direct_to_template takes the kwarg "template" and most > other generic views take "template_name". Smells a little like php to > me. > > Is this something that should be / can be fixed? Agreed that it is an annoying wart. I can see two ways we can address this. Firstly we can introduce a 'template_name' argument to direct_to_template that shadows the existing 'template' argument. An error would be raised if you specify both; using 'template' would raise a Deprecation warning. Secondly, we can ignore it in the current implementation, and use the migration to class-based generic views (#6735) as an excuse to clean up that bit of API. Patches welcome :-) Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Template filter for "in"
Ah, so it is. Thank you. Somehow I overlooked that one.
Any commentary on the filter implementation? My use case above, for `
{% firstof ... %}` was a little dodgy. A better use case would be
using the filter with the "with" tag. I've thought however that
altering "with" to also accept the "in" syntax would eliminate the
need for the filter.
Apologies for overlooking docs on the smarter if tag. I had read the
roadmap in passing several days ago, but had thought it was only
simplifying the various if-tags that currently exist.
Tim
On Nov 10, 1:56 pm, Alex Gaynor wrote:
> On Tue, Nov 10, 2009 at 3:54 PM, Tim wrote:
>
> > I haven't seen any notes on the subject, so I pose the question:
>
> > Would there be warm reception for a new built-in filter called "in",
> > to provide the template system with the Pythonic keyword? A full-blow
> > `{% if a in B %}` syntax would be great, but either one works. The
> > template language so intentionally mimes Python keywords that it seems
> > odd that "in" is left out.
>
> > You can imagine the simplicity of a filter, but in the name of being
> > quite specific as to what I'm suggesting:
>
> > �...@register.filter(name="in")
> > def _in(needle, haystack):
> > return needle in haystack
>
> > Pardon the PHP-ism of variable names.
>
> > I realize this is simple enough for a little custom templatetag
> > library to implement outside of the Django core, but it *does* fill in
> > that hole in the template language that I mentioned. My little
> > internal debates can't decide if the "in" functionality makes a better
> > if-tag extension, or if it's better suited as a filter. (Or both.) A
> > Filter is more appealing to me, because it can be used in several
> > other constructs, most notably `{% firstof ... %}`, as a simple
> > argument: "a|in:b".
>
> > Thus:
> > 1) Is this worth adding to the ticket system, with a patch, or
> > should I content myself to my little custom library filter?
> > 2) If it's worth the consideration, would a filter, a tag or both be
> > most appropriate?
>
> > Opinions obviously are welcome.
>
> > Tim
>
> This is already covered by the Templates-02 item on the 1.2 features
> list, the smart-if tag. This tag includes support for "in"
> operations.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
template or is it template_name
Stop me if you have heard this one before. Anyone else find it annoying that direct_to_template takes the kwarg "template" and most other generic views take "template_name". Smells a little like php to me. Is this something that should be / can be fixed? Sean --~--~-~--~~~---~--~~ 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 filter for "in"
On Tue, Nov 10, 2009 at 3:54 PM, Tim wrote:
>
> I haven't seen any notes on the subject, so I pose the question:
>
> Would there be warm reception for a new built-in filter called "in",
> to provide the template system with the Pythonic keyword? A full-blow
> `{% if a in B %}` syntax would be great, but either one works. The
> template language so intentionally mimes Python keywords that it seems
> odd that "in" is left out.
>
> You can imagine the simplicity of a filter, but in the name of being
> quite specific as to what I'm suggesting:
>
> �...@register.filter(name="in")
> def _in(needle, haystack):
> return needle in haystack
>
> Pardon the PHP-ism of variable names.
>
> I realize this is simple enough for a little custom templatetag
> library to implement outside of the Django core, but it *does* fill in
> that hole in the template language that I mentioned. My little
> internal debates can't decide if the "in" functionality makes a better
> if-tag extension, or if it's better suited as a filter. (Or both.) A
> Filter is more appealing to me, because it can be used in several
> other constructs, most notably `{% firstof ... %}`, as a simple
> argument: "a|in:b".
>
> Thus:
> 1) Is this worth adding to the ticket system, with a patch, or
> should I content myself to my little custom library filter?
> 2) If it's worth the consideration, would a filter, a tag or both be
> most appropriate?
>
> Opinions obviously are welcome.
>
> Tim
> >
>
This is already covered by the Templates-02 item on the 1.2 features
list, the smart-if tag. This tag includes support for "in"
operations.
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Template filter for "in"
I haven't seen any notes on the subject, so I pose the question:
Would there be warm reception for a new built-in filter called "in",
to provide the template system with the Pythonic keyword? A full-blow
`{% if a in B %}` syntax would be great, but either one works. The
template language so intentionally mimes Python keywords that it seems
odd that "in" is left out.
You can imagine the simplicity of a filter, but in the name of being
quite specific as to what I'm suggesting:
@register.filter(name="in")
def _in(needle, haystack):
return needle in haystack
Pardon the PHP-ism of variable names.
I realize this is simple enough for a little custom templatetag
library to implement outside of the Django core, but it *does* fill in
that hole in the template language that I mentioned. My little
internal debates can't decide if the "in" functionality makes a better
if-tag extension, or if it's better suited as a filter. (Or both.) A
Filter is more appealing to me, because it can be used in several
other constructs, most notably `{% firstof ... %}`, as a simple
argument: "a|in:b".
Thus:
1) Is this worth adding to the ticket system, with a patch, or
should I content myself to my little custom library filter?
2) If it's worth the consideration, would a filter, a tag or both be
most appropriate?
Opinions obviously are welcome.
Tim
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
ConFoo.ca Web Techno Conference
Esteemed django developers, I'm a coordinator for the Python track at ConFoo.ca, a major Web development conference in Montréal, featuring a very large array of Web related subjects including PHP, Python, Ruby, standards, security, scaling, and system administration. There are only a few days left to submit a talk proposal, and we would love to see some great Django-related talks at the conference! It'll be a unique chance to mingle with php, ruby, java web developers, and the python track is going to be a blast! You can find more information on our website: http://confoo.ca/en/cfp Apologies for the off-topic post on this mailing list! Best regards, -- Éric St-Jean estj...@confoo.ca Python track co-organizer, ConFoo.ca Web Techno Conference March 10th-12th 2010, Montréal, Québec --~--~-~--~~~---~--~~ 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: Regularly-scheduled Django sprints, first December 11 - 13
This is still a little ways out, but Mahalo.com will be hosting a sprint in the next round in February in Santa Monica, CA. We're still looking for core developers in the area, so if you know any or are one, let me know. -Jeff On Tue, Nov 10, 2009 at 9:06 AM, mrts wrote: > > Great news! Have you discussed the workflow yet? > I.e. will a DVCS be involved, and if yes, will there be > a central repo for coordinating the effort? > > A special repo on Github would otherwise be perfect, > but as mentioned before, we have a problem with re-forking: > > http://support.github.com/discussions/feature-requests/560-two-forks-of-a-single-repo > > Whatever workflow and tools have been or will be > picked, may I suggest that clear instructions be written > for participants -- e.g. something in the lines of [1]? > > [1] http://code.djangoproject.com/wiki/CollaborateOnGithub > > > --~--~-~--~~~---~--~~ 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: #7539 (ON DELETE support) aka ORM-09 - A call for feedback
Am 10.11.2009 um 17:22 schrieb Michael Glassford: > > I haven't had a chance to look at the patch yet, but what you describe > here sounds good. I don't have any problem with you "hijacking" the > work. > > Did your patch deal at all with the unit tests in my patch that > intentionally failed to expose things that weren't working right yet? Only the first of your patches contains tests. But the ON DELETE related tests in this patch that do not test database-level support should be covered by my tests in modeltests/on_delete/. Which of your tests failed? __ Johannes --~--~-~--~~~---~--~~ 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: Regularly-scheduled Django sprints, first December 11 - 13
Great news! Have you discussed the workflow yet? I.e. will a DVCS be involved, and if yes, will there be a central repo for coordinating the effort? A special repo on Github would otherwise be perfect, but as mentioned before, we have a problem with re-forking: http://support.github.com/discussions/feature-requests/560-two-forks-of-a-single-repo Whatever workflow and tools have been or will be picked, may I suggest that clear instructions be written for participants -- e.g. something in the lines of [1]? [1] http://code.djangoproject.com/wiki/CollaborateOnGithub --~--~-~--~~~---~--~~ 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: Regularly-scheduled Django sprints, first December 11 - 13
I'd be willing to help organize one in the Triangle area of North Carolina (Raleigh, Durham, Chapel Hill). We're just getting a Django Users Group setup (TriDjUG) and there is already a thriving Python Users Group (TriZPUG) in the area. I'm sure we could get a decent turn out. Thanks for kicking this off! Paul --~--~-~--~~~---~--~~ 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: Regularly-scheduled Django sprints, first December 11 - 13
I would be up for getting one together in Lawrence. Our offices at LJ World have always been a good place in the past, and I'm sure we can use them again. -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://ericholscher.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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #7539 (ON DELETE support) aka ORM-09 - A call for feedback
I haven't had a chance to look at the patch yet, but what you describe here sounds good. I don't have any problem with you "hijacking" the work. Did your patch deal at all with the unit tests in my patch that intentionally failed to expose things that weren't working right yet? Mike Johannes Dollinger wrote: > There's a new patch on the ticket[1], based on Michael Glassford's > work, that solves a few remaining issues and should be fully backwards > compatible. I haven't painted the bikeshed yet, so the API still is > `on_delete=CASCADE | SET_NONE | SET_DEFAULT | PROTECT | DO_NOTHING | > SET(value)`. Two minor additions: > > `DO_NOTHING` does nothing. Let the db handle it or resolve the > dependency in pre_delete (see: #10829 [2]) > > `SET(value)` sets the foreign key to an arbitrary value. `value` > may > be a callable, `SET(None)` is equivalent to `SET_NULL`. > > To make `on_delete` work on m2m intermediary models > `DeleteQuery.delete_batch_related()` had to go. Intermediary models > now use (almost) the same related-objects-collection code path as > every other model (thanks to m2m-refactor). Because that would have > lead to lots of SELECT queries for related objects, I refactored the > collection algorithm to collect batches of objects instead of > individual objects. That reduced the overhead to > `#INTERMEDIARY_INSTANCES / GET_ITERATOR_CHUNK_SIZE` queries. This > refactoring has a nice side-effect: Given the following code > > class A(models.Model): pass > class B(models.Model): a = models.ForeignKey(A) > class C(models.Model): b = models.ForeignKey(B) > > a = A.objects.create() > for i in xrange(100): B.objects.create(a=a) > a.delete() > > the `delete()` call results in 103 queries with trunk, and only 4 > queries with my patch applied. > > Finally, collecting related objects for auto_created intermediary > models is short-circuited to avoid the extra SELECTs completely. The > same could be done for any model that has no related objects, if we > didn't need the instances to send signals (Someday/Maybe: > Meta.send_signals = bool or tuple). > > Since the constants used for `on_delete` are just callables, it's > possible to do any kind of calculation to decide what should happen to > related instances, e.g.: > > def delete_or_setnull(collector, field, objects): > setnull = [] > cascade = [] > for obj in objects: > if can_delete(obj): > delete.append(obj) > else: > setnull.append(obj) > SET_NULL(collector, field, setnull) > CASCADE(collector, field, cascade) > > fk = ForeignKey(To, on_delete=delete_or_setnull, null=True) > > This should probably not be documented at first, but it would be a > nice feature once it's clear the on_delete handler signature will > remain stable. > > > FIXME: > * I'd like to introduce `DatabaseFeatures.can_defer_constraint_checks` > to disable nulling out foreign keys when it's not necessary. This > would save a couple of UPDATE queries. > > * There are ugly contrib.contenttypes imports in > `DeleteQuery.delete_batch_related()`. I left all contenttypes related > code there (just renamed the method, it's still called). Someday/Maybe > this could be removed and handled as a custom `on_delete` argument on > GenericForeignKey. > > * There are no docs. > > > Any feedback welcome. > > @glassfordm: If you're still working on this patch, I'd like to hear > what you think (and get those tests you mentioned). I'm sorry I > somewhat hijacked your work. > > __ > Johannes > > [1] http://code.djangoproject.com/ticket/7539 > [2] http://code.djangoproject.com/ticket/10829 > > > > > > > --~--~-~--~~~---~--~~ 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: Regularly-scheduled Django sprints, first December 11 - 13
> Sure that'd be great, I guess we don't really need to start planning > until it gets a little closer, but if we want to have any discussions > about the local things let's try to revive the django-chicago mailing > list :) > > Alex Yeah, I agree. If you need admin access to that list I think Tom can help with that. Sean --~--~-~--~~~---~--~~ 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: Regularly-scheduled Django sprints, first December 11 - 13
On Tue, Nov 10, 2009 at 11:14 AM, Sean Brant wrote: > > Alex, I can help you out in Chicago if you need it. > > Sean > > > > Sure that'd be great, I guess we don't really need to start planning until it gets a little closer, but if we want to have any discussions about the local things let's try to revive the django-chicago mailing list :) Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Regularly-scheduled Django sprints, first December 11 - 13
Alex, I can help you out in Chicago if you need it. Sean --~--~-~--~~~---~--~~ 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: Regularly-scheduled Django sprints, first December 11 - 13
On Tue, Nov 10, 2009 at 10:04 AM, Alex Gaynor wrote: ... > From December 19th through January 24th I will be willing to do > anything necessary to organize a sprint in Chicago, hopefully it won't > be too hard to drag our local core devs there :). Let me know what > the sprint date would be over that time period and I can start working > things out. Ah, winter break. :-) 2nd weekend is Jan 8-10, so let's say that? --~--~-~--~~~---~--~~ 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: Regularly-scheduled Django sprints, first December 11 - 13
On Tue, Nov 10, 2009 at 11:00 AM, Jeremy Dunck wrote: > > Djangonauts, > To help speed along development on Django, I'd like us to start > holding regularly-scheduled sprints. I've previously contacted core > committers to see who would be willing to supply the commit bits for > the sprint workflow. I'm now looking for members of the dev list to > help organize locally. If you would be willing to help organize your > local Django developers, the DSF can pay for lunches or similar costs. > It doesn't take much effort-- you just need a place to work that > offers a good network connection and a little coordination to get > people together. If you're an experienced contributor, great, but > there will be people on #django-dev and #django-sprint to help out, > too. We can certainly get a committer available online. In some > cases, we can get a committer on-site to help things along as well. > > To start, let's try running a sprint once every two months. I don't > think the specific days matter too much, but for a start, let's say > the second Friday through Sunday of every second month, starting in > December. That would make the first scheduled sprint December 11 - > 13. Since we have developers world-wide, I think it would make sense > to have the sprint roll across the time zones, starting at Fri 11 Dec > at 18:00 UTC [1] and running continuously until Mon 14 Dec at 00:00 > UTC [2]. Within that range of time, local groups can gather with some > assurance that a committer will be available at least virtually. > > It'd be lovely to get more than one location per sprint, and I'd > like to ensure that people all over at least have a reasonable chance > to attend a gathering. The exact days and start times will be up to > local organizers-- I'm just trying to make some conventions so we > don't have to fiddle with configuration so much. > > If you're willing to organize a sprint gathering during this time > span, please let me know and I'll help to ensure committers are > available and to promote the sprint gathering. (There's actually > pretty good guidance on the Sprints wiki page [3].) > > Even if you can't host on those dates, but would like to host in the > future, please let me know so I can have a list of candidates to work > from in the future. > > [1] > http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=11&hour=18&min=0&sec=0&p1=64&p2=37&p3=196 > [2] > http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=14&hour=0&min=0&sec=0&p1=64&p2=37&p3=196 > [3] > http://code.djangoproject.com/wiki/Sprints > > > > >From December 19th through January 24th I will be willing to do anything necessary to organize a sprint in Chicago, hopefully it won't be too hard to drag our local core devs there :). Let me know what the sprint date would be over that time period and I can start working things out. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Regularly-scheduled Django sprints, first December 11 - 13
Djangonauts, To help speed along development on Django, I'd like us to start holding regularly-scheduled sprints. I've previously contacted core committers to see who would be willing to supply the commit bits for the sprint workflow. I'm now looking for members of the dev list to help organize locally. If you would be willing to help organize your local Django developers, the DSF can pay for lunches or similar costs. It doesn't take much effort-- you just need a place to work that offers a good network connection and a little coordination to get people together. If you're an experienced contributor, great, but there will be people on #django-dev and #django-sprint to help out, too. We can certainly get a committer available online. In some cases, we can get a committer on-site to help things along as well. To start, let's try running a sprint once every two months. I don't think the specific days matter too much, but for a start, let's say the second Friday through Sunday of every second month, starting in December. That would make the first scheduled sprint December 11 - 13. Since we have developers world-wide, I think it would make sense to have the sprint roll across the time zones, starting at Fri 11 Dec at 18:00 UTC [1] and running continuously until Mon 14 Dec at 00:00 UTC [2]. Within that range of time, local groups can gather with some assurance that a committer will be available at least virtually. It'd be lovely to get more than one location per sprint, and I'd like to ensure that people all over at least have a reasonable chance to attend a gathering. The exact days and start times will be up to local organizers-- I'm just trying to make some conventions so we don't have to fiddle with configuration so much. If you're willing to organize a sprint gathering during this time span, please let me know and I'll help to ensure committers are available and to promote the sprint gathering. (There's actually pretty good guidance on the Sprints wiki page [3].) Even if you can't host on those dates, but would like to host in the future, please let me know so I can have a list of candidates to work from in the future. [1] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=11&hour=18&min=0&sec=0&p1=64&p2=37&p3=196 [2] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=14&hour=0&min=0&sec=0&p1=64&p2=37&p3=196 [3] http://code.djangoproject.com/wiki/Sprints --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ticket 9589: development server stops on SyntaxError or other Exceptions
#9589 http://code.djangoproject.com/ticket/9589 was closed for a reason that didn't make any sense--it looks like someone closed the ticket after reading only the first comment. The later patches fixed those problems. I asked about this in the ticket, but didn't get a response. -- Glenn Maynard --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
