Re: Can you add a build-in template tags?
你好！ pay attention： SSI ... “which must be specified using an absolute path -- in the current page it's not good for migrating. 谢谢！(thanks!) On 10月19日, 上午1时26分, dc wrote: > Please read > documentationhttp://docs.djangoproject.com/en/dev/ref/templates/builtins/#ssi --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Jogging: my take on 1.2 logging
I was inspired by all the logging discussions lately, so I wrote a wrapper for Python's logging module called jogging: http://github.com/zain/jogging My implementation looks a lot like the ideas proposed in the logging thread, so jogging might be useful to (at least) test out those ideas. I'd love your thoughts on whether this approach is viable for 1.2 or if jogging is better off as an app on pypi. Zain --~--~-~--~~~---~--~~ 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: Continuous Integration command
2009/10/18 Dougal Matthews > > It had been discussed recently; > http://groups.google.com/group/django-developers/browse_thread/thread/825b6a1b676f24ed/c54aa0fd48ed7b8c?hl=en&lnk=gst&q=failed#c54aa0fd48ed7b8c > Link fail. This one will work better; http://groups.google.com/group/django-developers/browse_thread/thread/825b6a1b676f24ed/c54aa0fd48ed7b8c Dougal --~--~-~--~~~---~--~~ 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: Continuous Integration command
2009/10/18 Anssi Kaariainen > > > Is it possible to autorun only the failing tests? It would be very > useful (at least for me) if the following was supported > No. Not yet anyway... It had been discussed recently; http://groups.google.com/group/django-developers/browse_thread/thread/825b6a1b676f24ed/c54aa0fd48ed7b8c?hl=en&lnk=gst&q=failed#c54aa0fd48ed7b8c --~--~-~--~~~---~--~~ 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: Continuous Integration command
On Oct 18, 8:08 pm, berto wrote: > Sounds like you're interpreting what I'm looking as a feature, a > bug. :) I want to write tests and see them fail continually until I > have written the code that makes them pass. Is it possible to autorun only the failing tests? It would be very useful (at least for me) if the following was supported: 1) run all the tests. 2) on file change, run tests that failed in step 1. 3) when no tests fail in step 2, run all the tests again. If failures, start from step 1 again. If no failures, print "Completed". --~--~-~--~~~---~--~~ 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: Can you add a build-in template tags?
Please read documentation http://docs.djangoproject.com/en/dev/ref/templates/builtins/#ssi --~--~-~--~~~---~--~~ 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: Continuous Integration command
On Oct 18, 7:24 am, Russell Keith-Magee wrote: > On Sun, Oct 18, 2009 at 6:14 PM, berto wrote: > > > On Oct 17, 5:33 pm, Russell Keith-Magee > > wrote: > >> I'd like to fix this problem, but while this problem exists, adding a > >> continuous integration server that crashes every time the developer > >> makes a Syntax Error doesn't sound like an especially good idea. > > > That's an excellent point. My initial implementation did have the > > same problem, but I have since fixed it as well as runserver. The > > changes are posted on github: > > > - autoreload patch adds checking for modifications on files in an > > errored state > > http://github.com/rca/django/commit/ef96339f7e766700e8739a591b226b63b... > > > - runserver patch adds files that have errors to the autoreload code > > changed loop > > http://github.com/rca/django/commit/e1d0be02b001155a09b012f4867de1efd... > > > - updated version of runtester using the functionality above: > > http://github.com/rca/django/commit/043e9723ae8fdb98745c2390f3ff92649... > > - and a minor patch to it: > > http://github.com/rca/django/commit/c1d62dbb58b1113a864ed5b1d35dd0b60... > > That's great - but if you leave it on github, it's going to get forgotten. > > This issue is being tracked on ticket #9589. If you want to ensure > this contribution isn't forgotten, turn your github changeset into a > patch, and upload that patch to the ticket. You can also reference the > github changeset in the ticket comments, but not all the Django core > uses git. > > > But, just like the test command, the runtester command takes a list of > > apps, or even a TestCase class within an app. That way you are simply > > running a subset of the tests on the app actively being worked on. > > For example: > > > ./manage.py runtester some_app.SubTest > > > With the above command, only the SubTest tests are run, which will > > drastically reduce the time to run the tests. Granted time to setup > > and teardown of the test environment is still there. > > Well, sure, except for the fact that if you do this, you no longer > have continuous integration :-) The point of a test suite is that you > run *all* the tests, so that you can catch *all* the possible > regressions. Sure - if you're just doing a quick check of something, > you might just run a single test, but you need to run the full suite > to be sure. Maybe I used the wrong name to describe the feature? I was basically looking for a way to run tests related to the work currently being done. I'm not suggesting that running the entire test suite is not necessary, surely it is. > That's why I suggest that CI is better suited as a checkin trigger. A > checkin is an indication that you think a body of work is complete. > Running the full test suite is then an appropriate validation step. A > single file save doesn't give you that sort of certainty that a body > of work is complete. I think we're in agreement here. > When it takes a while for a test suite to run (which will be true in > Django even if you're only running a small subset of the overall > suite), it could be easy for a test suite to start running on a > partially saved set of updates, which could result in confusion over > exactly which version of a which files were used to run a test. Sounds like you're interpreting what I'm looking as a feature, a bug. :) I want to write tests and see them fail continually until I have written the code that makes them pass. > kGiven the fact that it takes a long time to setup and teardown > Django's test suite, I feel that it is better to leave test execution > as a manually invoked process. That way the developer can be certain > of the exact file versions that will be used for a test run. Alright, well, thanks for your input. I'll use the test runner throughout the project I'm working on and see how useful it actually is! -berto. --~--~-~--~~~---~--~~ 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: Can you add a build-in template tags?
On Sun, Oct 18, 2009 at 12:18 PM, butterhuang wrote:
> There is a templatetags {% include 'x.html' %}, it's very nice. may a
> templatetags like {% include no-parse "x.html"} is needed. It's so
> powerful to improve the speed of include some static files which has
> no variable,and it's so easy for you guys, isn't it?
This would be a lot easier to discuss if you (or someone else) can
show us (a) an implementation of such a tag, and (b) some profiling
numbers that demonstrate significant savings with your method.
Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.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
-~--~~~~--~~--~--~---
Can you add a build-in template tags?
There is a templatetags {% include 'x.html' %}, it's very nice. may a
templatetags like {% include no-parse "x.html"} is needed. It's so
powerful to improve the speed of include some static files which has
no variable,and it's so easy for you guys, isn't it?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal for 1.2: Improved URL system
Hi LeafStorm, On Oct 18, 6:52 am, Jannis Leidel wrote: > Hi LeafStorm, > > > Okay, I guess I can live with that. Maybe, if I can write a patch > > implementing this in a completely backwards-compatible way, I'll > > propose it again for a later version (earlier in the release cycle). > > In the meantime you might want to have a look at Surlex, Cody > Soyland's 3rd party app that does pretty much what you > propose:http://codysoyland.com/blog/2009/sep/6/introduction-surlex/ I also did something like this. You can find it here: http://bitbucket.org/orutherfurd/django-easyurls/ docs and examples start here: http://bitbucket.org/orutherfurd/django-easyurls/src/tip/easyurls.py#cl-30 -Ollie --~--~-~--~~~---~--~~ 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: Looking for a solid django/python developer...
Hi Sanford -- This is the wrong place for a posting like this -- django-developers is for discussion of core Django development. You'll be better off posting this to django-users and/or djangogigs.com. Good luck! 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ANN: Critical security updates to Django 1.0 and Django 1.1
On Sat, 2009-10-17 at 04:40 -0700, klas.hagg...@hotmail.com wrote: > How come the new regular expression allows TLDs to end with a '.' > character? For example 'n...@domain.com.' (note the period at the end) > is regarded as a valid email address. Perhaps because it is a valid domain name? http://www.tcpipguide.com/free/t_AbsoluteFullyQualifiedandRelativePartiallyQualifie.htm -- "XML is like violence: if it doesn't solve your problem, you aren't using enough of it." - Chris Maden --~--~-~--~~~---~--~~ 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: Continuous Integration command
On Sat, Oct 17, 2009 at 09:59:38AM -0700, berto wrote: > I wanted to be able to run a project's test suite in the same manner > runserver restarts when a file is changed. I did not find this > feature in Django so I wrote the following code: Have you looked at http://github.com/lacostej/nosyd yet? This seems might be of interest based on what you are looking for. As an added bonus it allready supports Django :) -Thomas Adamcik --~--~-~--~~~---~--~~ 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: Continuous Integration command
On Sun, Oct 18, 2009 at 6:14 PM, berto wrote: > > On Oct 17, 5:33 pm, Russell Keith-Magee > wrote: >> I'd like to fix this problem, but while this problem exists, adding a >> continuous integration server that crashes every time the developer >> makes a Syntax Error doesn't sound like an especially good idea. > > That's an excellent point. My initial implementation did have the > same problem, but I have since fixed it as well as runserver. The > changes are posted on github: > > - autoreload patch adds checking for modifications on files in an > errored state > http://github.com/rca/django/commit/ef96339f7e766700e8739a591b226b63b91cdcf7 > > - runserver patch adds files that have errors to the autoreload code > changed loop > http://github.com/rca/django/commit/e1d0be02b001155a09b012f4867de1efd14454b4 > > - updated version of runtester using the functionality above: > http://github.com/rca/django/commit/043e9723ae8fdb98745c2390f3ff92649bc106df > - and a minor patch to it: > > http://github.com/rca/django/commit/c1d62dbb58b1113a864ed5b1d35dd0b60ec2c071 That's great - but if you leave it on github, it's going to get forgotten. This issue is being tracked on ticket #9589. If you want to ensure this contribution isn't forgotten, turn your github changeset into a patch, and upload that patch to the ticket. You can also reference the github changeset in the ticket comments, but not all the Django core uses git. > But, just like the test command, the runtester command takes a list of > apps, or even a TestCase class within an app. That way you are simply > running a subset of the tests on the app actively being worked on. > For example: > > ./manage.py runtester some_app.SubTest > > With the above command, only the SubTest tests are run, which will > drastically reduce the time to run the tests. Granted time to setup > and teardown of the test environment is still there. Well, sure, except for the fact that if you do this, you no longer have continuous integration :-) The point of a test suite is that you run *all* the tests, so that you can catch *all* the possible regressions. Sure - if you're just doing a quick check of something, you might just run a single test, but you need to run the full suite to be sure. That's why I suggest that CI is better suited as a checkin trigger. A checkin is an indication that you think a body of work is complete. Running the full test suite is then an appropriate validation step. A single file save doesn't give you that sort of certainty that a body of work is complete. When it takes a while for a test suite to run (which will be true in Django even if you're only running a small subset of the overall suite), it could be easy for a test suite to start running on a partially saved set of updates, which could result in confusion over exactly which version of a which files were used to run a test. kGiven the fact that it takes a long time to setup and teardown Django's test suite, I feel that it is better to leave test execution as a manually invoked process. That way the developer can be certain of the exact file versions that will be used for a test run. 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: Proposal for 1.2: Improved URL system
2009/10/18 Maxim Penzin > > Another crazy idea for shorter object fetch is > "/%(model_name.id)d/" or may be another syntax like "/%%(model_name)/" > to get rid of > get_object_or_404( id=int(id) ) > at the first line of every view method. > I quite like this idea, not sure about that syntax exactly but the idea is nice. Personally I'm a fan of regular expressions so wouldn't want to see them removed or abstracted to a level that really isn't that different. Something like this however would be more interesting as as you say it skips a bit of code that ends up in many views. It could also be used pass the view pre-filtered querysets. Say for example with date based filters. i.e. /2009/, /2009/09/ and /2009/09/09/ would go to the same view but rather than pass the date or date parts the view is passed the result of a Model.objects.filter() However, I'm at a total loss of how the syntax for this would work :) --~--~-~--~~~---~--~~ 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: AddWYSIWYGEditor
On Sun, Oct 18, 2009 at 8:28 PM, diover wrote: > > How I can use any AddWYSIWYGEditor in Django? Django-developers is a mailing list for discussing the development of Django itself. General questions of usage or problem solving should be directed to django-users. 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 -~--~~~~--~~--~--~---
AddWYSIWYGEditor
How I can use any AddWYSIWYGEditor 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal for 1.2: Improved URL system
> My proposal is to add a URL resolution system on top of the current
> one [for backwards compatibility] that works in a similar way to
> Werkzeug's URL resolver. You express URL patterns in a syntax like '/
> /' (where the first 'slug' is a converter and the second
> 'slug' is the name to be passed), which is then converted into a
> regular expression to match URLs ('/(?P[A-Za-z0-9_-]+)/'), and a
> format string ('/%(slug)s/'). When resolving, the regular expression
> is matched against the URL, and when reversing, the variables are
> validated and then substituted into the format string. There would
> probably be converters for 'string', 'slug', 'number', 'monthname',
> etc. The advantages of this system are:
'pythonic' %(slug)s syntax is a good idea.
Regexes are very flexible but we don't need it in most cases.
Another crazy idea for shorter object fetch is
"/%(model_name.id)d/" or may be another syntax like "/%%(model_name)/"
to get rid of
get_object_or_404( id=int(id) )
at the first line of every view method.
--
-- mpen...@gmail.com icq:3861496 www.penzin.ru --
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
question on how django handles nested if blocks
I'm trying to get a feel for how the template system works, but
something is confusing me regarding nested blocks.
Lets say we have a simple template:
{% if foo %}
hello
{% if bar %}
bye
{% endif %}
{% else %}
{% endif %}
Seems like the lexer would produce the following tokens:
So when we create a nodelist, I'd expect the parse statement:
nodelist_true = parser.parse(('else', 'endif'))
To return the nodes for:
And not the expected:
Am I missing something about how the lexer/parser does it's magic? I
don't see how nesting would be handled in the current code, and it's
driving me crazy not knowing how it works.
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal for 1.2: Improved URL system
Hi LeafStorm, > Okay, I guess I can live with that. Maybe, if I can write a patch > implementing this in a completely backwards-compatible way, I'll > propose it again for a later version (earlier in the release cycle). In the meantime you might want to have a look at Surlex, Cody Soyland's 3rd party app that does pretty much what you propose: http://codysoyland.com/blog/2009/sep/6/introduction-surlex/ . Best, Janis --~--~-~--~~~---~--~~ 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: Continuous Integration command
On Oct 17, 5:33 pm, Russell Keith-Magee wrote: > On Sun, Oct 18, 2009 at 12:59 AM, berto wrote: > > > Hello developers, > > > I wanted to be able to run a project's test suite in the same manner > > runserver restarts when a file is changed. I did not find this > > feature in Django so I wrote the following code: > > >http://www.djangosnippets.org/snippets/1763/ > > > I think it would be useful to others and would like to propose to add > > it into the core Django project. > > This is an interesting proposal. I'm not completely convinced, though, > for a couple of reasons. > > 1) runserver is not especially robust to certain types of errors, such > as SyntaxError. I will admit that I haven't tried the snippet that you > referenced, but it looks like it will be prone to the same problem. > I'd like to fix this problem, but while this problem exists, adding a > continuous integration server that crashes every time the developer > makes a Syntax Error doesn't sound like an especially good idea. That's an excellent point. My initial implementation did have the same problem, but I have since fixed it as well as runserver. The changes are posted on github: - autoreload patch adds checking for modifications on files in an errored state http://github.com/rca/django/commit/ef96339f7e766700e8739a591b226b63b91cdcf7 - runserver patch adds files that have errors to the autoreload code changed loop http://github.com/rca/django/commit/e1d0be02b001155a09b012f4867de1efd14454b4 - updated version of runtester using the functionality above: http://github.com/rca/django/commit/043e9723ae8fdb98745c2390f3ff92649bc106df - and a minor patch to it: http://github.com/rca/django/commit/c1d62dbb58b1113a864ed5b1d35dd0b60ec2c071 > 2) I'm not necessarily convinced that a CI services should be running > on a developers box during development. Ah, but when doing test-driven development, it's what one does. My current workflow is: while True: write_tests() while are_tests_failing(): write_code() run_tests() > Django's test suite takes a > long time to run - I've heard reports of test durations measured in > *hours* for some setups. Test durations like this aren't really > compatible with a "retest on every file change" CI approach. Given the > current state of Django's test framework, I'm more convinced that a CI > server based on checkins is more appropriate. I can't really argue against your point that, if a test suite takes hours, run it elsewhere. But, just like the test command, the runtester command takes a list of apps, or even a TestCase class within an app. That way you are simply running a subset of the tests on the app actively being worked on. For example: ./manage.py runtester some_app.SubTest With the above command, only the SubTest tests are run, which will drastically reduce the time to run the tests. Granted time to setup and teardown of the test environment is still there. > 3) Most of my hesitation on (2) is driven by the fact that > setup/teardown is such an expensive operation. Most of the time spend > running the test suite isn't spent running tests - it's spent setting > up and tearing down tests. We've made some big improvements by using > transactions to speed up this process, but it's still slow. If you > want to convince me that per-file-modification CI is worthwhile, > you'll need to work out a way to dramatically reduce the > setup/teardown time for tests. Much of this concern might be mitigated by listing the desired apps/ test cases to test when the command is run as described above. > 4) An alternate approach is to come up with a smarter way to run tests > so that the tests that are important to the file being modified > (whatever that means) are run more often, rather than just blanket > running the entire suite. This might mean reducing the CI process to a > Monte Carlo style sampling that eventually results in 100% coverage if > the file base remains stable for long enough. Quite an interesting idea. I can't afford to spend the time to really hash this concept out though. :\ Thanks for the reply, -berto. --~--~-~--~~~---~--~~ 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: #9886: HttpRequest refactoring
Russell Keith-Magee wrote: > Any complete feature is potentially a candidate for > v1.2 - as long as you can convince a core developer to look into the > ticket. This is what I'm trying to do, yes :-). The ticket is assigned to Malcolm (and in fact it was created after we talked with him if such a thing is needed) but he's incredibly busy lately so I decided to discuss it here to get someone else interested. > It's also worth noting that one of the GSoC projects was "HTTP/WSGI > improvements". If you want to get #9886 into trunk, I suspect you > would be well advised to see how your patch integrates with the > changes on the soc2009 branch for that project. I had that in mind from the beginning of that GSoC but didn't look at the code yet. Since the ticket is older than the GSoC branch there were chances that it would be committed earlier. But of course I'll keep an eye on the process. From a fast superficial look at the code we don't seem to conflict anyway :-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
