Re: contrib.admindocs need some love.
On Thu, Aug 27, 2009 at 5:03 PM, Alex Gaynor wrote: > > On Thu, Aug 27, 2009 at 4:03 PM, Justin Lilly > wrote: > > Hey guys. > > > > I started writing some docs for another developer today and hit a few > > issues with admindocs that I plan on sprinting on for DjangoCon. I'm > > hoping anyone else with complaints / ideas will voice up, though my main > > impetus for the post is to announce that I'm going to do it so I > > can't back out. ;) > > > > Things I plan to address: > > > > 1. No tests. > > 2. No docs. > > 3. You can't seem to cross-link to views without the link being > > app.package.func . I'd like to see it at least configurable. > > I've actually got a patch that fixes this on my github django repo in > the "admindocs" branch. > > > 4. ManyToManyFields don't show up. > > > > I don't see this problem, for example User/Group show the relationship > in both directions correctly, since you clearly don't see it there's > probably some more debugging work needed here to figure it all out. Yea, James committed this before 1.1 went out. http://code.djangoproject.com/changeset/11128 http://code.djangoproject.com/changeset/11127 Cheers, Eric --~--~-~--~~~---~--~~ 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: Question on ticket triage process
At first glance, tests and documentation. Everything needs both of these things before they go into trunk. Having a complete patch like that will make it a lot easier for someone to see what you're doing, and verify that you have fixed it. Cheers, Eric --~--~-~--~~~---~--~~ 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: built-in logging with django.core.log
I have looked into Logging before for another project, and I found that
SQLAlchemy's support seemed to be a pretty good model to follow. They define
all of their loggers under the sqlalchemy namespace, and then you can
configure different handlers for different things[1]:
import logging
logging.basicConfig()
logging.getLogger('sqlalchemy.engine').setLevel(logging.INFO)
logging.getLogger('sqlalchemy.orm.unitofwork').setLevel(logging.DEBUG)
I think that this would be necessary to have in Django, so that for
instance, I could listen to the django.orm logs, and not the django.http, or
listen to them with different handlers/levels.
Their implementation[2] is a little confusing to me, but I think that having
some prior art like this will allow us to better understand what we need,
and how to accomplish it, so I thought I would throw it out there.
1: http://www.sqlalchemy.org/docs/05/dbengine.html#configuring-logging
2:
http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/lib/sqlalchemy/log.py
--
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: 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 -~--~~~~--~~--~--~---
Improving (and testing!) bash completion
Hey all,
I recently was looking for a way to add bash completion to a management
command that I made. With changeset 11526[0] during the djangocon sprints,
bash completion was moved from bash into Python. Now there is a super basic
bash script that calls django-admin.py with the correct environment for it
to autocomplete.
Now that the code is in Python, this lets us do a lot more with it. As
implemented, a custom management command's options (--settings, --list) will
be autocompleted. There is currently no way to define arguments to your
function that will be autocompleted. I went ahead and looked through the
code today and wrote up some proof of concept code that does just this.
What I did
First thing I did was write tests for the current behavior[1]. No tests were
written for the original commit, so if nothing else, these tests should be
commited. The link there works for the current environment, then I added a
few more tests that test my changes as well.
After that, I implemented a basic API for declaring a completion in a
Command class[2]. I will describe here the implemented API. I'm hoping that
people have some ideas about the correct way to implement this.
Currently, your Command class will define a complete() function along with
your handle() function. The complete() function can then return two
different things. In the simple case, it can return a simple list of
arguments that it expects to be able to handle. These will be passed along
to the bash completion, and complete appropriately.
So for example if your custom command 'check_site' had a complete() command
that returned ['ljworld', 'kusports', 'lcom'], and on the command line you
did `django-admin.py check_site ljw`, it would return ljworld.
The more complex case is where you want to be able to define multiple
positional arguments for a command. Currently, this is implemented by
returning a dict with the key being the number that you want to complete
(this sucks. So you could do something like:
def complete(self):
return {
'0': ['ljworld', 'kusports']
'1': ['year', 'week', 'day']
}
Then you would be able to do `django-admin.py ljworld ye` and it would
return `year`.
Currently there is also special casing for returning All Installed Apps, and
All Installed Commands. I went ahead and made a magic symlbol "APP_NAME" and
"COMMAND_NAME" that will evaluate to these lists. Both of these APIs seem a
bit hacky.
So currently I am thinking about making the following changes to make this
stuff a bit better.
Proposal
===
I think that instead of special casing[3] the commands that take an APP_NAME
etc., we would put the complete() function on the BaseCommand, and then for
built-in commands that want custom bash completion, use the proposed API to
define it.
Instead of using simple strings for APP_NAME and COMMAND_NAME, we put these
as constants on the base command class. These could either be special cased
in the bash completion script, like currently, or actually make these
evaluate to the actual list they represent. Computing both of these values
isn't processor intensive, so it would make sense to just have them there.
I don't know what exactly we should do to represent commands that want
control over specific arguments. The current dict with keys of ints seems
silly, but I don't know a much better way. Perhaps represent this as a list
of lists, where index 0 would be the same as the dict['0'].
This would make a basic class end up looking something like this:
def complete(self):
return [
['awesome', 'sweet'],
BaseCommand.SUBCOMMANDS,
BaseCommand.INSTALLED_APPS,
]
Please let me know what you all think, and what I have missed. Implementing
these changes would resolve a lot of the special casing in the bash
completion, and turn it into a real API that is useful for management
command authors. I think that this is a big win. Bash completion is one of
those things that is super useful, but a damned pain to implement.
Abstracting it this way would make a lot of our commands grow bash
completion I would bet.
[0] http://code.djangoproject.com/changeset/11526
[1]
http://github.com/ericholscher/django/commit/eceda439ab1a950230bd5f792d3f8baef86a56a7
[2]
http://github.com/ericholscher/django/commit/b48b261d2533b45fd7bb955e50869aa1f41bab7b#L0R330
[3]
http://code.djangoproject.com/browser/django/trunk/django/core/management/__init__.py?rev=11526#L313
--
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-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=.
Re: Call for comment: #12624 Class based test runners
Saw this go in, and it gets a huge +1 from me as well. However, I know that in the past we have talked about adding other things to the test runner (like coverage, etc), so it would seem like now would be a good time to recommend accepting **kwargs in your custom test runners, so that when we add in more abilities in the future, we don't blow up people's old test runners that they have that don't support new options. Otherwise this patch looks good, thanks for the work Russ. Cheers, Eric -- 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.
Re: Getting Problem in connecting mysql (Help me please )
Hi,
Django Developers is for development on Django. For usage questions you want
django-users: http://groups.google.com/group/django-users
Cheers,
Eric
On Thu, Jan 28, 2010 at 8:48 AM, rokson wrote:
> This is kiran .
> i am new to django fw.i installed django fw and trying to connect
> mysql which is installed in localhost.i am using python 26.i modified
> settings.py according to the mysql db.
> when i am running server. i am getting the fallowing error.
>
> plese help me..
>
>
>
>
> C:\kiranproj\myappone>python manage.py runserver
> Validating models...
> Unhandled exception in thread started by 0x013079F0>
> Traceback (most recent call last):
> File "C:\Python26\lib\site-packages\django\core\management\commands
> \runserver.
> py", line 48, in inner_run
>self.validate(display_num_errors=True)
> File "C:\Python26\lib\site-packages\django\core\management\base.py",
> line 249,
> in validate
>num_errors = get_validation_errors(s, app)
> File "C:\Python26\lib\site-packages\django\core\management
> \validation.py", lin
> e 22, in get_validation_errors
>from django.db import models, connection
> File "C:\Python26\lib\site-packages\django\db\__init__.py", line 41,
> in e>
>backend = load_backend(settings.DATABASE_ENGINE)
> File "C:\Python26\lib\site-packages\django\db\__init__.py", line 22,
> in load_b
> ackend
>return import_module('.base', backend_name)
> File "C:\Python26\lib\site-packages\django\utils\importlib.py", line
> 35, in im
> port_module
>__import__(name)
> File "C:\Python26\lib\site-packages\django\db\backends\mysql
> \base.py", line 13
> , in
>raise ImproperlyConfigured("Error loading MySQLdb module: %s" % e)
> django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb
> module: No mo
> dule named MySQLdb
>
> --
> 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.
>
>
--
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-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.
Re: Refining Django admin look proposal
I went ahead and replied to this on my blog[0]. I'll copy it here for completeness. [0]: http://ericholscher.com/blog/2010/feb/6/role-designers-django-community/ There has been a recent discussion on the Django Development mailing list about the role of designers in the Django community. I think that this is an interesting discussion that can come from this, and I would like to explain my thoughts on the issue. This discussion came up in the context of redesigning the Django Admin, which everyone knows and loves. The UI is growing a bit out-dated, and there was talk of working to clean it up. This then turned into a discussion about how design proposals and improvements aren't taken as seriously as they should be by the community. I think there are a number of reasons that this happens, and I would like to take a look at them. My purpose here is to start a discussion about how to better integrate designers into the community, because they are a vital part of making our world more beautiful and efficient. I don't trust myself to judge your work === The normal process for changes that go into Django is that a proposal is sent to the mailing list. There is a discussion that happens around them, and then if the code is produced, and it works, it gets committed. For design changes, I don't reply to these messages, because I don't have the skills or knowledge to judge the work. I think that a lot of people on these lists are in the same boat. When someone sends a proposal to the list, and it doesn't get any replies, that feels like rejection. This happens more than it should, but it isn't anyones job to respond to these messages and say "sorry, I'm not qualified to critique your work". This happens with code proposals too, but I think it may happen more with design. This leads to designers forsaking the mailing list, and this problem perpetuates itself, by not drawing designers into the community. Design is not special, except when it is Part of the problem that seems to have come forward is that there is a feeling that design is "special". That it should be treated somehow differently in the process. As we know from history, even with all good intentions, different is never equal. So I think that we should work to fit design into the current scheme of how things work, instead of trying to adopt new ways of dealing with it. When I look at the current Core Developers of Django, I don't see many people who are designers. As I said above, that fact that very few of the current core developers are well versed in the design realm, really hurts inclusion of design changes. This creates a lot more friction in the process of getting design changes into the code base. I don't know if this idea is crazy, but should we have the concept of a "core designer". These would be people that the community trusts and knows have good taste, that would be an obvious person to make these design choices. I think that there is a problem when I have a design change for Django, and I really don't know who to talk to. There is an obvious authority (BDFL) for code changes, but I don't know if Adrian and Jacob are really the correct people to making these judgment calls on design? I realize that this is open source, and "core designers" would be the same as developers, just people who care about the direction of the projects design. However, I think that having more design oriented people in the community in a more direct fashion would make it more obvious that design changes are welcomed and seriously considered. I don't know how far we need to go down the path of making this explicit. However, most of the documentation about contributing is explicit about "code". This is another of those lines, where I don't know if it makes sense to be explicit about design, having a "design" section in the contributing documentation, or if the implicit knowledge of core designers will make it obvious that we mean design changes there too. The actual process == I don't want to talk about the actual design process, because well, I really don't know how it works. I think that once we integrate designers into the community better, the process for design will naturally fall out better. Conclusion == I would like to point out that Django has some of the best designers of any open source community out there. I am lucky to work with a number of them on a daily basis, and I really think that they make our community special. So thank you guys for sticking with us. This is a place where I could see Django leading the way in how to integrate design into the open source development process. Let's make a grand experiment, and see how it works out. -- 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 gr
Re: Django Design Czar
On Sat, Feb 6, 2010 at 6:26 PM, j...@jeffcroft.com wrote: > First off, I'm generally on board with everything you've said here. > Only three points/questions I'd like to make: > > 1. I wouldn't say "Wilson is out of the picture" without talking to > him first. I know he's a busy man and my impression is that he doesn't > have time for this right now, but I'm certainly not going to speak for > him on that matter. Hopefully he'll speak up and let us know (I do > know he's been following this discussion, at least casually). I > totally agree that what we're really talking about now is find his > successor, but let's not start doing so without confirming with him > that he doesn't still want this position -- in my opinion, he should > have first dibs on it if he wants it. > Totally agreed. I think that Wilson's input will be very valuable in this process. He is the one who was around and knows the development process at World Online that allowed the current admin and templates to be formed. I am really curious what exactly that is. I don't want him to feel like we're pushing him out in any way. He has a brilliant designer, and his input is totally appreciated. I think that he is already implicitly part of this team of core designers, being a core dev and a designer, if he has the time. (I like this terminology, "core designer", since it doesn't imply one person, and everyone immediately knows what it means). > > 2. Is there value in having more than one "design czar?" As in, would > it be better to have a small team handling this rather than one > person? I'm not sure I know the answer, but I do worry that any one > person sets us up for the situation we're in with Wilson -- where > someone is the "leader", but doesn't really have the time or resources > to do that job (either temporarily or permanently). I'm not sure what > my own opinion is one this one, yet, but I thought I'd rase the > question. Clearly we don't need a ton of people, but maybe a few? > > 3. On the topic of Wilson: let's be clear that none of this is his > fault. He did a spectacular job on the admin interface, and never > formally received a "design czar" like position in the community that > I know of. He's busy like many of us, and he hasn't let us down at > all, in my opinion. > Totally agreed. Like in my original post, this is open source. Nobody is required to do anything. He has given us so much work that I am grateful for, and Django is in a better place because. It's more of a social signal that we really do care about design, and actually have the people who can step up and do something about it. Wilson was that person in the beginning, being the defacto person who deals with design decision for the project. I agree he was never appointed, but that is how things worked. If we are trying to establish process, or ideas about how to perform a similar role, then the only thing that we have to look at is how it was previously done. Luckily we have an excellent model of how things worked previously, and they seemed to work pretty damn well. So hopefully we can emulate that going forward, and produce similarly awesome results. Cheers, Eric -- 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.
Re: Django Design Czar
> > I'm opposed to this. Firstly, unless I've missed something whoever > gets the position, would definitionally get it before they've done > anything! This is completely antithetical to the spirit of open > source, meritocracy. Why should design be treated any different from > other changes to Django? Changes to the design of the admin should be > handled in the same way as any changes, for a large change someone > writes up a proposal, starts work, asks for review, finalizes, and it > gets committed. That being said there is no reason a designer > couldn't have a commit bit, Wilson certainly does, but they'd have to > earn it the same way anyone else does. We don't need a formalized > process to get input from designers we trust, I ask for review from > tons of people who have no formal standing in the Django community > when I have questions that pertain to their area of expertise. > > In conclusion, there is 0 reason design needs to be treated different > from a procedural perspective. > > Alex > First off, there are designers who have contributed great amounts of stuff to the Django community. Nathan Borror has his Basic Apps (which interestingly is a designer contributing code, because that's what he can contribute easily). The Grapelli team has that project which represents a large amount of open source code in the design realm around the project. There are countless others that have put in the time, and helped out around here. It's not like we're going to take in some random designer, these are people that we know and trust. I agree that this should be treated in the same way as development, is that not what we're proposing? We have the same role for a designer on the core team as for a developer. This seems like we are doing the same thing? It's not like the Czar/Core designer person will be able to just make commits to the code base whenever they want with no oversight. They will be just like a normal committer, people will be able to veto things and everything else. It just means that we have people who really know what they are talking about with design to make those decisions. A similar idea is when Simon asked for feedback on the security issues with Django's signing infrastructure. We don't have experts on the team to make those calls, so we need to bring in people who are knowledge in that area. If there was someone in the community who has contributed a lot, and knew a ton about security, it would seem like a no brainer to make them a committer, with a Czar-like power over security issues. I am merely proposing we do the same thing with design. Cheers, Eric -- 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.
Re: Serialization of single object instead of only querysets.
Use Django Piston. It will make your life a ton easier. Cheers, Eric On Wed, Feb 17, 2010 at 11:48 AM, orokusaki wrote: > Addendum: I might be simply abusing `serialize`. I'm using it as a > Django compatible `json.dumps` in order to provide a JSON API from my > models to my JSON-RPC client. There seems to be no more extensible > way. If this isn't one of the intended uses, let me know and I'll > leave it alone. Again I apologize for any apparent allusion of > hostility towards Django or the developers. I'm your #1 fan (ran here > as fast as I could from RoR a year ago). > > -- > 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. > > -- 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-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.
Django's testing infrastructure
Hey everyone, During the sprints, I worked to set up a hudson instance for Django. This is hopefully going to be the way that we are going to go forward for now with doing continuous integration for Django. I have a pretty good setup going currently, and want make it really fantastic. At this point in time, what we really need now is some more hardware to be able to run tests on. The current setup is hosted at: http://hudson.djangoproject.com/ Currently, I have tests running on the following architectures: Django trunk: Solaris: Python 2.4-2.5 Databases: sqlite, postgres, mysql Ubuntu: Python 2.5-2.6 Databases: sqlite, postgres, mysql Django 1.1.X: Solaris: Python 2.5 Databases: sqlite, postgres This gives us pretty good coverage currently, but the whole point of doing CI is that we catch bugs on other platforms we wouldn't normally run on. What we need === So I'm looking for people who can offer other boxes that they would like to see tested. Currently the big ones we aren't covering are Windows boxes, and the Oracle backends. There are lots of other permutations that we could be testing against (Different python runtimes being a good example). However, we don't want to get in a situation where boxes that people have set up just disappear. So, I'm only currently looking for machines that people would be able to dedicate to the effort. We would require a django-testing user account on the box, with our SSH key on it. There would also be a team of trusted users, who would have access to this key and thus your machine. We want the build farm to be stable and useful, and in the past we have had too much trouble having machines just disappear. Requirements === Currently the hudson requirements seem to be about <1GB of disk space, with 512MB of ram. I'm also looking into some pony build/barn based alternatives that would knock the memory requirements down pretty substantially. However, for the current 1.2 release it looks like hudson is how we're going to make it going forward. Note that for $20/mo a 512MB machine can be run on Rackspace cloud, so another way that we might be able to get this going is to be able to have donations to the DSF, and have them get some dedicated rackspace boxes. However, for now, I'm hoping that we can cobble together enough stuff to get 1.2 tested really well. Feedback == If you have any thoughts on CI, or any advice, I would love to hear it. I'm trying to make our Continuous Integration setup really kick ass, so feedback is necessary to do this. I have some notes and ideas that I have been recording while setting things up over at the pycon etherpad: http://pyconpads.net/django-testing Let me know if you have any thoughts, questions, or concerns. Cheers, Eric -- 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.
Re: Django's testing infrastructure
Awesome response! Thanks for the offering of support everyone. Luckily, with hudson, it's pretty simple to get this all set up. We basically just need to figure out what the infrastructure looks like. I don't know if it's going to make more sense to try and set up dedicated Database servers, or try and set up each client to have the necessary databases running on each one. Currently, all I need for a slave machine is a box with a publically accessable IP, with an account with the Django Testmaster's key on it. Hudson will take care of everything from there, at least on the Django side. Hudson will ssh in and pull down Java if necessary, then run itself as a client. It seems we will need to have some kind of standard setup for the databases, with either local connections being let through without auth, or with a standard username and password (maybe django/django), so that we can do the database operations. If anyone has much experience here, I'll probably be doing some benchmarking to figure out what kind of app to database server ratio we need, and what makes sense in that regard. I'll give this some more thought this weekend, and try and email everyone who has offered support. I know there is a django-buildbots mailing list that never got used last time we did this, i dunno if we want to keep the conversation here and more public, or put it over there and keep the archives around for setting stuff up. Thanks again for all the offers, it's really great, now we just need to figure out how to scale this up without using lots of human hours in the process. Cheers, Eric On Fri, Feb 26, 2010 at 1:08 PM, Mikhail Korobov wrote: > That's great news, thanks! > > A very minor issue: web server returns 'Content-Type:text/ > html;charset=ISO-8859-1' header for this page: > http://hudson.djangoproject.com/monitor/? > but the actual page encoding is utf-8 so there are strange symbols > instead of translated strings. > > -- > 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. > > -- 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-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.
Re: New context template tag
I usually use James Bennett's django-template-utils for this purpose. It has
a nice, simple implementation:
http://bitbucket.org/ubernostrum/django-template-utils/src/tip/template_utils/nodes.py#cl-11
It still requires the annoying Node/function split though.
I know there have been a multitude of third party attempts at improving
Django's template tags, and I think it's commonly agreed that they are one
of the more boilerplatey bits. Sadly none of the third party libraries have
really become defacto, so it's hard to think about including any of them in
core. It does seem like a place that could use some expose either in the
docs or in the general community though.
Cheers,
Eric
On Thu, Jul 22, 2010 at 9:26 AM, Alex Robbins wrote:
> I am a huge fan of simple_tag and inclusion_tag. They take a common
> template tag use case and make it very easy to write. It seems like a
> common use case that isn't represented is adding a value to context. I
> find myself writing tags to add a variable to context very often and
> it seems like we should be able to abstract this out.
>
> I'm thinking it would work like this, but would love to get feedback
>
> @register.add_to_context_tag
> def tag_name():
>do_some_python()
>return context_value
>
> This would turn into a tag that worked like this:
>
> {% tag_name as variable %}
>
> Which puts context_value into the context as variable.
>
>
> It could optionally take takes_context, and work like this. This would
> make context the required first argument to the function, like
> inclusion_tag.
>
> @register.add_to_context_tag(takes_context=True)
> def tag_name(context):
>do_some_python_that_needs_context(context)
>return context_value
> --
>
> Finally, it could take arguments like simple_tag or inclusion tag.
>
> @register.add_to_context_tag
> def tag_name(some, arguments, it, takes):
>some_func(some, arguments)
>return context_value
>
> which would yield a tag that worked like this:
>
> {% tag_name some arguments it takes as variable %}
>
> -
> Is this a use case other people have? Can anyone think of a better
> name than add_to_context_tag?
>
> Thanks,
> Alex
>
> --
> 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.
>
>
--
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-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.
Re: Accessible Command Output using self.stdout & self.stderr
>
>
> Q1. Should I create a separate, new module with my tests in it, or
> just add tests to an existing module? If an existing one, how do I
> determine which one?
>
It depends if your work is similar to anything else that is already in the
repository. I don't think that the stdout and stdin changing have explicit
tests -- although they are tested implicitly by being used in other tests.
>
> Q2. In attempting my first test one change, it seems as though the
> changes had had no effect. Have I missed some vital understanding...
> I changed the last line of management/commands/flush.py thus
>
> -print "Flush cancelled."
> +self.stdout.write("Flush cancelled.\n")
>
> and created a basic test thus:
>
>def test_flush(self):
>new_io = StringIO.StringIO()
>management.call_command('flush', verbosity=0,
> interactive=True)
>command_output = new_io.getvalue().strip()
>self.assertEqual(command_output, "Flush cancelled.")
>
You need to pass in your custom stdout into the call_command function. You
can see[1] where it takes those inputs and assigns them to your provided
values.
[1]
http://github.com/django/django/blob/master/django/core/management/base.py#L216
Cheers,
Eric
--
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.
Re: Call for use cases of metrics in django core
A couple obvious places: Latency to backend systems. So, any time that I call out to my cache backend or database, keep track of round trip latency of those. Full system latency. So, From the time a request enters the URL routing until it gets sent back to a client. Request counts. Keep track of the number of times a specific view or urlconf entry has been hit. This might be a bit intensive, and not worth having on. Average latency for every view. So you can keep track of what views are the slowest. Query counts on a per-view and overall system view. Cache hit rates as viewed by the cache backend. Error counts on a per-view basis. Also probably for any backend system interface. These are the first things that came to me. I'm sure some of them are a bit heavy weight for what we want to do. There are likely also other places where you would want to provide stats. As for implementation, we've been using mmstats[0] at Urban Airship successfully. It does require C bits, so it might not be great for Django, especially in regards to pypy integration. However, it is pretty darn low overhead, and might be worth at least stealing some ideas from. 0: http://mmstats.readthedocs.org/en/latest/ Cheers, Eric On Wednesday, October 31, 2012 3:41:05 PM UTC-7, jdunck wrote: > > If you use/monitor/graph metrics (the idea, not Coda's library, but that > would be good, too), I'd like to hear from you. > > What sort of metrics, under what implementation, would be useful to you > operationally? > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/6fJavfHAVNgJ. 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: structural & functional review of django documentation
On Monday, December 28, 2015 at 4:52:36 PM UTC-8, Daniele Procida wrote: > > On Mon, Dec 28, 2015, Samuel Bishop > > wrote: > The main existing sections are: > > * tutorials (/intro) > > Tutorials take the new user by the hand through a series of steps. The > important thing isn't to explain all the steps, but to achieve something > useful with a minimum of effort. > > After every step of a tutorial, the user should have something that works, > even if they barely understand what is happening (and it's not necessary > for them to understand, that can come later. What matters is that they are > successful). > > * how-to guides (/howto) > > How-to guides are recipes that take the user through steps in key > subjects. They are more advanced than tutorials and assume a lot more about > what the user already knows than tutorials do, and unlike documents in the > tutorial they can stand alone. > > * discussion and explanation (/topic) > > Aimed at explaining (at a fairly high level) rather than doing. > > * reference (/ref) > > Technical reference for APIs, key models and so on. It doesn't need to > explain so much as describe and instruct. > > I think the above post does a good job of describing the layout, and something similar should be included in the docs. Without having read Jacob's posts on the subject, there is nothing in the official docs that gives the reader an understanding that this is how things are laid out, as far as I know. I think the underlying structure makes sense, and it seems that mostly people are just upset about the lack of a pure auto-generated code reference. I believe historically that this has been excluded explicitly, not because of lack of technology. There is no use of autodoc in the Django tree, even where it might make sense. At Django Under the Hood this year, I had a few conversations with folks about rethinking and explicitly defining these policies. I think it makes a lot of sense to write down the logic and structure behind these decisions in a DEP, and explain the layout to doc users in a few places in the documentation explicitly. Cheers, Eric -- 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/0daa98a8-6714-4f76-adb2-ea5ced43d361%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: structural & functional review of django documentation
On Tuesday, December 29, 2015 at 2:17:31 PM UTC-8, Tim Graham wrote: > > > Turning the table of contents page into a CSS menu sounds like a possibly > worthwhile task. > > There is also an idea here for adding navigation breadcrumbs to the > documentation which might help: > https://github.com/django/djangoproject.com/issues/403 > Yea, I think the global TOC that the Read the Docs theme has is pretty good at surfacing the structure of the docs: http://docs.readthedocs.org/en/latest/ -- it allows users to see where in the hierarchy they are, and what levels make sense. That is already what is generating the TOC that is on the contents page, so it would be pretty easy to include that in the sidebar for the docs (I believe it's the `toc` variable in the Jinja template, but Django is using the custom JSON backend, which works differently). I think Django's TOC is quite large, so it would be hard to make it fit nicely into the sidebar, but having the information available one each page would likely be useful for UX. Perhaps you could at least do the top-level items, and an expanded view of the current tree (the `collapse` option here http://sphinx-doc.org/templating.html#toctree) > > > On Tuesday, December 29, 2015 at 4:48:37 PM UTC-5, Tim Allen wrote: >> >> Tim: that's definitely a big help, but still a click away. I'm just >> brainstorming here, please bear with me! >> >> I think part of my confusion as a newbie is from the front page itself, >> at https://docs.djangoproject.com/ >> >> Now that I understand the concepts behind the documentation better >> (thanks Daniele), it doesn't appear to be very well reflected on the front >> page. There is a list of First steps, The model layer, and so on, but >> nothing in the interface that clearly lets the user know that the >> documentation is meant to be broken down into the "Tutorials / How-To / >> Explanation & Discussion / Reference" paradigm. If that's what we are >> trying to communicate, it should be shown to the user from the front of the >> documentation clearly, IMHO. >> >> A top-down, browsable hierarchy would have been extremely useful to me >> when I was just getting started. The ToC has the kind of hierarchy I'm >> referring to (https://docs.djangoproject.com/en/1.9/contents/), but >> comes across to the user as a wall of text / links. Perhaps developing the >> ToC into a navigation menu is worth some effort? >> >> Does anyone else feel there is far too much on the front page? An >> experienced Django dev will be more comfortable finding what they need >> within the documentation, am I alone in thinking a much more simple front >> page might be useful to the newcomer? >> >> Regards, >> >> Tim >> >> On Tuesday, December 29, 2015 at 11:25:40 AM UTC-5, Tim Graham wrote: >>> >>> I've refined Daniele's explanation here: >>> https://github.com/django/django/pull/5888 >>> >>> Let me know if it helps and what could be better. >>> >>> On Monday, December 28, 2015 at 11:31:30 PM UTC-5, Eric Holscher wrote: >>>> >>>> >>>> >>>> On Monday, December 28, 2015 at 4:52:36 PM UTC-8, Daniele Procida wrote: >>>>> >>>>> On Mon, Dec 28, 2015, Samuel Bishop wrote: >>>>> The main existing sections are: >>>>> >>>>> * tutorials (/intro) >>>>> >>>>> Tutorials take the new user by the hand through a series of steps. The >>>>> important thing isn't to explain all the steps, but to achieve something >>>>> useful with a minimum of effort. >>>>> >>>>> After every step of a tutorial, the user should have something that >>>>> works, even if they barely understand what is happening (and it's not >>>>> necessary for them to understand, that can come later. What matters is >>>>> that >>>>> they are successful). >>>>> >>>>> * how-to guides (/howto) >>>>> >>>>> How-to guides are recipes that take the user through steps in key >>>>> subjects. They are more advanced than tutorials and assume a lot more >>>>> about >>>>> what the user already knows than tutorials do, and unlike documents in >>>>> the >>>>> tutorial they can stand alone. >>>>> >>>>> * discussion and explanation (/topic) >>>>> >>>>> Aimed at explaining
Re: A prompt 1.2.3 release
> There was a hudson server running IIRC, but > http://hudson.djangoproject.com/ is not responding to me. > > I took the hudson instance down because nobody was using it and it was costing me a decent amount of money to run per month. I still have the images around on Rackspace Cloud if the DSF or anyone actually wants to pay to have good CI. Just as a data point, I took it down about a month ago, and people only just noticed during the sprints. I don't know how to fix that particular problem. Cheers, Eric -- 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.
Re: Application, tempaltetags and namespace
Cody Soyland has also done some work on this in a reusable app, which might be useful as a starting point: http://github.com/codysoyland/django-smart-load-tag Cheers, Eric -- 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-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.
Re: Contributing more
Hey Laurent, Glad to hear you want to help out! The first step that I usually take is figuring out what component I want to work on. This is usually based around what I have the most familiarity with, or what part I'm interested in learning more about. Trac has nice features for filtering down by component, so for example I usually work on stuff with the test framework, so I'd use something like this: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&group=component&component=Testing+framework&milestone=1.3&order=priority Then once you find a ticket that looks interesting, I'd start with the triage process. The contributing docs are good to read to figure out what style of patches are good, and what the triage stages look like: http://docs.djangoproject.com/en/1.2/internals/contributing/#submitting-patches However, as a quick primer, I'd just look for tickets that are "Accepted", and if they have a patch, review them. If you think they are ready to go into trunk (have docs & tests, good style), feel free to mark them as "Ready For Checkin". This shows a core committer patches that should be checked in soon. If you find something without a patch, I'd go ahead and confirm that the issue is real, and then go ahead and try to fix it! Looking through Django's source and fixing things is usually good fun. In the spirit of Wikipedia, "Be Bold". Cheers, Eric On Sun, Oct 3, 2010 at 9:11 PM, Laurent Luce wrote: > Hello, > > I added the localflavor for Belgium as my first contribution. I would > like to contribute more code wise. I looked at the tickets with > milestone 1.3 and with no patch. It is hard to know what is critical > and where help is the most needed. > > Can someone tell me what tickets require immediate help and are not > too complicated for a new contributor. I don't mind spending 2-3 days > before Oct 18th. I have been using Django for 2 years and I am quite > familiar with the basics like views, models, templates and forms. > > Please let me know. > > Laurent > > -- > 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. > > -- 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-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.
Re: DjangoCon meetup Friday Sept 5
I think the TWID guys are doing something as well. Might want to combine groups. Eric On Wed, Aug 20, 2008 at 11:21 PM, Jonathan Nelson <[EMAIL PROTECTED]>wrote: > > I'm planning a get together the night before DjangoCon for people > going to the conference. I figured it would be nice to get to know > each other a bit better before sitting in a conference together all > weekend. > > I'm assuming that most people are going to be staying at the Hotel > Avante where the block of rooms was reserved for the conference. So, > I've talked to the hotel, and they've said that we can use the patio > by the pool for the meetup. We can probably fit about 30 people > there. > > If a lot more people show up, or if people aren't staying at the > hotel, there's a billiard club across the street that's big enough to > accommodate a larger group. > > I've set up a meetup page for the event here: > http://django.meetup.com/3/ > > Please RSVP if you're thinking about attending. If the RSVP's fill > up, we can move the venue across the street or find some place else. > > If anyone else can think of a better place to post this information, > let me know. Comments and thoughts are always welcome. > > Jonathan > > > > -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://www.ericholscher.com [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: I want a pony: Django Cheeseshop
Yea, I totally agree with this. I wrote a blog post about how to use setuptools and distutils to distribute 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 Django community). I have been tempted to package other people's apps and put them on Pypi and then hand over control if they wanted it, but that seemed rather heavy handed. Some kind of official suggestion, or just a culture of putting apps up there would be huge. I really think that everyones apps should be up on Pypi. Eric On Wed, Sep 10, 2008 at 10:57 AM, James Bennett <[EMAIL PROTECTED]>wrote: > > On Wed, Sep 10, 2008 at 9:31 AM, mrts <[EMAIL PROTECTED]> wrote: > > * create a central app index à la Cheeseshop > > Doesn't the Cheese Shop already exist? > > > * create an automated system similar to easy_install for installing > > apps from > > o that central repository > > "easy_install django-registration" works fine for me right now. Why > not encourage people to use standard Python practices for packaging > and distribution? > > > o either globally to Python packages -- *but under django namespace! > > * > > o or locally into a concrete project > > Does anybody else actually do this? Last I checked, Pylons, TurboGears > and Zope apps didn't install or need to be installed into > framework-specific locations. Django applications are just Python > modules, and that's a *strength* from where I sit. > > > * provide app dependency handling like setuptools does for > > o python package dependencies (identical to setuptools 'depends') > > o Django app dependencies (e.g. 'django_app_depends') > > Or just, you know, use setuptools. > > > * bundle the install tool either as a command for manage.py or a > > separate utility in bin > > Or just, you know, install setuptools. > > > * create the solution so that it can be adopted by other projects by > > clearly decoupling Django-specific functionality (i.e. engage more > > brainpower and devs) > > Or just use the existing packaging and distribution tools Python already > has. > > Have I made my point clear enough yet? > > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of > correct." > > > > -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://www.ericholscher.com [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: I want a pony: Django Cheeseshop
Haha, yea, sorry. On Wed, Sep 10, 2008 at 11:17 AM, Karen Tracey <[EMAIL PROTECTED]> wrote: > On Wed, Sep 10, 2008 at 12:12 PM, Eric Holscher <[EMAIL PROTECTED]>wrote: > >> Yea, I totally agree with this. >> >> I wrote a blog post about how to use setuptools and distutils to >> distribute 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 Django community). >> > > Did you mean 'Python community' there? (I did not see the talk, so trying > to understand...) > > Karen > > > > > -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://www.ericholscher.com [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Running tests.py in apps without models.py
You can just put a models.py there that is empty. A slight hack, but it should work just fine. (Think of it as __init__.py's big brother :)) Eric On Tue, Sep 23, 2008 at 2:27 PM, Adam J. Forster <[EMAIL PROTECTED]>wrote: > > Firstly I'm sorry if I have posted this in the wrong place, but I > think that it belongs here and not on the django-users list. > > Here's my problem, in most of our projects at work we have an app > called 'core' which contains modules that are either used by several > other apps or are not specific/large enough to justify their being in > their own apps. > > Today I needed to write some doctests for a function in core.utils so > I created a tests.py file inside core and placed my doctest there. > When I attempted to run the tests using 'manage.py test' I found that > they were not being run, when I ran 'manage.py test core' I got the > following error: > > django.core.exceptions.ImproperlyConfigured: App with label core could > not be found > > After some digging around in the Django source code I found the > problem. django.test.simple.run_tests makes calls to either > django.db.models.get_apps or django.gb.models.get_app to identify > which app(s) to search for tests. These functions return the models > module for the app, if the app does not contain a models module it is > not considered to be a valid app and is therefore not searched for > tests. > > This is not the first time that I have had an app which does not > contain a models module, and I can foresee that I will do the same > thing in the future. These apps may not contain models but they still > have code which needs testing. > > So my question is should I file this as a bug and start working on a > patch for simple.run_tests that checks all INSTALLED_APPS for both > models.py and tests.py when searching for tests? Or is this something > which is not likely to change, in which case would I be better off > writing my own test runner instead? > > Kind regards, > -- > Adam J. Forster > > > -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://www.ericholscher.com [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Optional {% default %} clause for the {% for %} template tag
{% for color in patches %}
Bikeshed: {{ color }}
{% default %}
Person who writes the patch decides
{% endfor %}
I like empty/default or else. Use else if your main target is python people.
Use empty or default if your targetting it to designers. It really doesn't
matter which..
On Thu, Oct 30, 2008 at 12:29 PM, Antoni Aloy <[EMAIL PROTECTED]> wrote:
>
> 2008/10/30 Mike Panchenko <[EMAIL PROTECTED]>:
> > +1 for {% empty %}
> >
> > I also think this would be very useful
> >
> > On Thu, Oct 30, 2008 at 6:55 AM, dc <[EMAIL PROTECTED]> wrote:
> >>
> >> How about
> >>
> >> {% for item in items %}
> >> {% otherwise %}
> >> {% endfor %}
> >>
>
> +1 to the otherwise tag :)
>
>
> --
> Antoni Aloy López
> Blog: http://trespams.com
> Site: http://apsl.net
>
> >
>
--
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://www.ericholscher.com
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: 1.1 feature: unify access to response.context in test client
Note also, that sometimes the context that you are looking for isn't always in [0]. I ran into this when I was writing testmaker, and had to hack around it. Luckily all of my templates used inheritance, so I didn't get bitten by the dictionary or list of dictionary part. I did something like this: con = context.dicts[0] if 'MEDIA_URL' in con: con = context.dicts[-1] Obviously a hack, but it seems to work most of the time. For my pony request, it would be really nice to have a way to get "user defined" context. This being things that were passed from views, set in template tags, (and maybe other places?). That is what the above code is trying to do. I haven't thought about how to do it, but I agree with James that some thought needs to be placed into this. A simple workaround might be to flatten the lists in request.context, but then keys in the dictionaries might be overwritten. On Sat, Nov 8, 2008 at 2:56 PM, James Bennett <[EMAIL PROTECTED]> wrote: > > The Django test client exposes the Context used to render the returned > response, so that unit tests can inspect that Context and verify that > it contained what it was expected to contain. This is all well and > good, except that there is no consistent way to write tests which do > this. > > When an inheritance chain of multiple templates is used to render the > response, ``response.context`` is a list of dictionaries, > corresponding to the Context at each template and so, for example, one > might want to check ``response.context[0]['some_var']``. But when > inheritance is not used, ``response.context`` is simply a dictionary, > leading to a check lik ``response.context['some_var']``. > > This makes it extremely difficult/tedious to write truly portable unit > tests, since a test which passes on one installation of an application > might fail on another for no other reason than that the type of > ``request.context`` has changed from dictionary to list, or > vice-versa, raising spurious ``TypeError`` or ``KeyError`` depending > on which way it changed. > > For a real-world example, consider django-registration: I have a local > project set up to run its unit tests, with minimal (non-inheriting) > templates; the test suite accesses ``request.context`` > dictionary-style, and passes. But a user of django-registration > attempted to run the test suite on an installation which uses > inheritance, and saw multiple test failures as a result: > > > http://www.bitbucket.org/ubernostrum/django-registration/issue/3/failed-in-test > > I believe quite strongly that unit tests, if they are to be useful, > need to be portable. And currently, it seems the only way to make them > portable is to include type checks on response.context each time a > test will inspect the context, e.g.,:: > >if isinstance(response.context, list): >self.assertEqual(response.context[0]['foo'], 'bar') >else: >self.assertEqual(response.context['foo'], 'bar') > > This is painful and ugly. > > For 1.1, could we look into unifying the interface to > ``response.context`` to avoid this sort of problem? Unless I'm > thinking about this the wrong way, it shouldn't be too hard to > differentiate dictionary-style access from list-style access, since > the former -- in the case of a Context -- will always be using string > keys and the latter will always be using integer indexes. > > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of > correct." > > > > -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://www.ericholscher.com [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django & memcache hashing
Just wanted to say that we ran into this exact issue at work the other day as well. We had the C and Python versions of memcache running, and it was hashing things differently (to different servers or something as I understand it). This caused us a good couple hours of confusion. We eventually figured it out and made sure that each of our boxes had the same version of memcache. On Thu, Nov 20, 2008 at 3:01 AM, Ludvig Ericson <[EMAIL PROTECTED]>wrote: > > On Nov 20, 2008, at 05:20, Ivan Sagalaev wrote: > > What concerns me is that this will break the usage of memcached > > without > > Django's cache API. I had the need a couple of times to do plain > > instantiation of memcache.Client and work with it. If it won't see the > > cache the same way as Django does it would be that very issue, hard to > > debug, that started this thread. > > True, but that's because python-memcached for some reason still uses its > own hashing algorithm (pure CRC32) while other libraries are more or > less > unified in their hashing algorithm. (Wouldn't know about libmemcached.) > > *ugh* Why can you never eat the pie and have it. :( > > - Ludvig > > > > -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://www.ericholscher.com [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: twitvn
Check out http://twitter.com/DjangoTracker Eric On Fri, Dec 5, 2008 at 1:02 PM, David Reynolds <[EMAIL PROTECTED]>wrote: > > Hi, > > Since a lot of Djangonauts and Django Developers are using twitter, > would anyone find it useful to get svn commit messages on twitter? > > There seem to be a drop in svn hooks script called twitvn [0] that can > be used. > > I've seen other people following the Wordpress [1] one and thought it > might be quite interesting and useful to have one for Django. > > Thoughts? > > 0 - http://code.google.com/p/twitvn/ > 1 - http://twitter.com/wpdevel > > -- > David Reynolds > [EMAIL PROTECTED] > > > > > -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://ericholscher.com [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Perl port of the django template system.
Name it whatever you want. It's your bikeshed. Eric On Sun, Dec 21, 2008 at 11:55 PM, Maluku wrote: > > DTL seems to be too short... > > What about "Dotiac" (DjangO Template Interpreter And Compiler), which > works as a name and an abbreviation. > > Maluku > > > > > -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://ericholscher.com e...@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 -~--~~~~--~~--~--~---
1.1 Sprints and roadmap
It looks like January 15 is when the Major Feature freeze happens (and that is in about 2 weeks). The roadmap[1] says that there will be 1.1 sprints starting in late december, which has come and is quickly fading. Just figured I would start the discussion on when/where some sprints will be happening. If we want some kind of decent attendence before the 15th, these are going to have to be scheduled pretty soon. Also, does the major feature freeze mean that the features must be committed, or that they have have significant amounts of work done? (I don't see any of the "Must have"s for 1.1 having been committed..) Cheers, Eric 1: http://code.djangoproject.com/wiki/Version1.1Roadmap --~--~-~--~~~---~--~~ 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: Rolling back tests -- status and open issues
ed by some if code changes are required to use it. > But I did want to point out that the effects of the re-ordering done to put > the rolled-back transaction test cases first may be a little more subtle > than expected, in case that sways anyone's opinion towards requiring opt-in > for getting the new behavior. > > Karen > > > > > I would also like to point out a kind of edge case. The Ellington test suite is currently using the approach in #5624[1], where we are injected fixtures into doctests by declaring a __fixtures__ argument inside of a doctest. This is currently being run with a patched Test Runner that applies the fixture (if present), and then calls the doctest.DocTestRunner.run itself. This is having to apply a flush before every call it loaddata (basically mimicking transactions, but much slower). I think that if there is a plan to ever include fixtures into doctests, then we should put transaction management into them. We should also decide on a syntax (__fixtures__ really isn't too bad). This is mostly a bikeshed, where if it's going to happen, we just need to decide something that works and go with it. Otherwise we should go ahead and close #5624, and say that doctests are only for simple cases where you are generating the objects yourself. This means that we will internally write out doctests that require fixtures back into unit tests, but this isn't a huge deal. I think we should just decide now, and stick with it. I really don't have a preference, because I don't think that doctests should be used as extensively as they are. I know a big reason they were used before is because they were faster, which now a moot point. If we just say "we will never have fixtures or transactions on doctests", then we can just be done with it. 1: http://code.djangoproject.com/ticket/5624 Cheers, Eric -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://ericholscher.com e...@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: Rolling back tests -- status and open issues
On Thu, Jan 15, 2009 at 12:06 PM, Karen Tracey wrote: > On Wed, Jan 14, 2009 at 5:35 PM, Russell Keith-Magee < > freakboy3...@gmail.com> wrote: > >> >> On Thu, Jan 15, 2009 at 5:40 AM, Eric Holscher >> wrote: >> > I think that if there is a plan to ever include fixtures into doctests, >> then >> > we should put transaction management into them. We should also decide on >> a >> > syntax (__fixtures__ really isn't too bad). This is mostly a bikeshed, >> where >> > if it's going to happen, we just need to decide something that works and >> go >> > with it. Otherwise we should go ahead and close #5624, and say that >> doctests >> > are only for simple cases where you are generating the objects yourself. >> > This means that we will internally write out doctests that require >> fixtures >> > back into unit tests, but this isn't a huge deal. >> > >> > I think we should just decide now, and stick with it. I really don't >> have a >> > preference, because I don't think that doctests should be used as >> > extensively as they are. I know a big reason they were used before is >> > because they were faster, which now a moot point. If we just say "we >> will >> > never have fixtures or transactions on doctests", then we can just be >> done >> > with it. >> > >> > 1: http://code.djangoproject.com/ticket/5624 >> >> There is two issues at work here. >> 1) Is #5625 a good idea? >> 2) Do we need to implement it right now? >> >> Regardless of the answer to (1), (2) is the more pressing concern - >> given that we're days away from a v1.1 feature freeze, and we're >> probably behind schedule as it is, now isn't the time to start with >> unnecessary feature creep. As far as I can tell, #5625 can be safely >> deferred to v1.2 without losing functionality or being boxed into a >> corner by #8138. Given that there isn't any urgency brought on by a >> need to meet v1.1 commitments, I suggest that we should defer this >> discussion to the next planning cycle. >> > > I agree. As it is now #8138 doesn't change the behavior of doctests, so > far as I know. Trying to do the same thing for them as was done for > django.test.UnitTest code -- running them in a rolled-back transaction and > preventing them from calling transaction routines -- led to more weird > errors in the Django test suite. Given time I'm sure they can be figured > out, but I think there's some design work involved in order to come up with > a way for them to opt-out of the change, as TestCases can do by switching to > TransactionTestCase. It seems there is similar work to be done for > extending them to auto-load fixtures, and it would make sense coordinate > that work so that all Django "doctest extensions" have a similar feel, use a > consistent mechanism, etc. But we don't have time to do that for 1.1, I > don't think. But I don't think it's necessary to say at this point we can > never do it. > > I'm hopeful #8138 can go in (today -- to make the major feature freeze > deadline?) for 1.1 pretty much as it is now. It provides good speedup for > Django TestCases. So far as I know doctests are now unaffected by it -- if > I'm missing something there in terms of the latest patch on #8138 breaking > doctests please let me know. > > Karen > > > > You both are indeed correct. I certainly think that the current patch can go in today as presented. The Ellington test suite is passing with a 10x speedup. We can get it to 40x speedup if we change out doctests that load fixtures into unit tests (which probably makes more sense anyway). From 2 hours down to 3 minutes is amazing. Thanks for all the hard work, and I'm really excited to see this going into Django. Django development will be much improved with this change. Cheers, Eric -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://ericholscher.com e...@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: Contenttype Generation Inconsistency During Serialization
On Wed, Feb 11, 2009 at 1:48 PM, jameslon...@gmail.com < jameslon...@gmail.com> wrote: > > There is a small road block that makes contenttype a little dangerous > to use during application development. Especially in regards to > serializing your data to different databases. During syncdb the > contenttypes are generated in a way that makes regeneration at a later > date inconsistent with the previously generated primary keys. > > The contenttype IDs can be different depending on when your syncdb was > run in the development of your application. In addition, loaddata and > dumpdata are prevented from working correctly if the contenttypes have > already been created (integrity errors). > > My use pattern for this is during application development I would > architect all of my data models before adding any explicit indexes. > After the models are complete and data is loaded I will analyze the > use patterns and index accordingly. Since django has no way of syncing > indexes my approach would be to dump the data to a JSON file, drop the > database and use syncdb to create the canonical copy. > > My experience was as follows: > 1st Try: > 1. Dump data from old db using management command (dumpdata) > 2. Drop DB and use django to create the database via syncdb > 3. Load data using management command on the new database > 4. Become irritated with integrity errors while the load tries to > import the contenttype table which already exists. > 2nd Try: > 1. Dump data from old db using management command (dumpdata), > excluding the contenttype table (-e contenttypes) > 2. Drop DB and use django to create the database via syncdb > 3. Load data using management command on the new database > 4. Realize all data is completely useless since contenttype's PK's > are not connected to the same models as before. > 3rd Try: > 1. Dump data from old db using management command (dumpdata) > 2. Drop DB and use django to create the database via syncdb > 3. Truncate contenttype table > 4. Load data using management command on the new database > > > Possible solution that doesn't suck a lot: > I came up with quite a few different ways to handle this, but the best > so far (even thought it's not stellar) is to create a new column in > contenttypes that's a combined column. The combined column would > contain the app_label and model_name. > > GenericForeignKey could use the combined column instead of the PK to > keep the references pointing to the same locations. I understand there > are some performance implications here, but it's the best I can come > up with. I would love to hear thoughts on this topic. > > > I have run into this problem as well, and have come up with a basic solution (for content types). The code is here: http://dpaste.com/119487/ . It is implemented as a serializer, which you would plug into django, and then use for serialization and deserialization of models with content types. It is rather simple (only about 10 lines of additional code). When it is dumping data, it checks to see if the field it is dumping is a content type, and if so, it dumps a dictionary of app_label and model. Then, when this fixture is loaded back in, it runs a query against the Content Types for that object. Then plugs that in for the content type. This fixes the problem of content types being an ID, and the ID's not matching when you move across databases (Your try #2). I have also been working on a more generic solution to this problem. I have a copy of it on github(1). The approach taken there is similar. When it loads a ForeignKey field to be serialized, it checks the related model (the one being pointed to) for any unique constraints. If any of these exist, then the model is dumped as a dictionary of kwargs containing the key/value pair for these unique constraints. The content type model doesn't define app_label and model as unique, which is a problem for this approach. If this ever gets into django core, it's going to require a special case for content type things (or some other approach which I haven't thought of). Having references to contrib apps is frowned upon, so I think having a third party serializer that does this is the answer for now. Hope this helps 1. http://github.com/ericholscher/sandbox/blob/d32da8c36f257bb973a5c0b0fd8f9bca79062f11/serializers/yamlfk.py -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://ericholscher.com e...@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: Contenttype Generation Inconsistency During Serialization
On Wed, Feb 11, 2009 at 4:59 PM, jameslon...@gmail.com < jameslon...@gmail.com> wrote: > > This is a great solution; when I wrote this post I was sure no one had > really run into the problem. I will use this for serializing my DB in > the future. Though, the last paragraph of your reply states that > content type doesn't define app_label and model as unique. I believe > that this is true now, at least mine appears to have a unique > constraint on it right away. Ah yes, you're right. I was looking at the model definition, but they're declared unique in the Meta unique_together. > > > This is still a legitimate issue during serialization, it's great to > see someone has made steps in the right direction. Glad it's been helpful. I want to get this into a more generic solution, and hopefully get part of it into django or a real third party app. > > > On Feb 11, 3:45 pm, Eric Holscher wrote: > > On Wed, Feb 11, 2009 at 1:48 PM, jameslon...@gmail.com < > > > > > > > > jameslon...@gmail.com> wrote: > > > > > There is a small road block that makes contenttype a little dangerous > > > to use during application development. Especially in regards to > > > serializing your data to different databases. During syncdb the > > > contenttypes are generated in a way that makes regeneration at a later > > > date inconsistent with the previously generated primary keys. > > > > > The contenttype IDs can be different depending on when your syncdb was > > > run in the development of your application. In addition, loaddata and > > > dumpdata are prevented from working correctly if the contenttypes have > > > already been created (integrity errors). > > > > > My use pattern for this is during application development I would > > > architect all of my data models before adding any explicit indexes. > > > After the models are complete and data is loaded I will analyze the > > > use patterns and index accordingly. Since django has no way of syncing > > > indexes my approach would be to dump the data to a JSON file, drop the > > > database and use syncdb to create the canonical copy. > > > > > My experience was as follows: > > > 1st Try: > > > 1. Dump data from old db using management command (dumpdata) > > > 2. Drop DB and use django to create the database via syncdb > > > 3. Load data using management command on the new database > > > 4. Become irritated with integrity errors while the load tries to > > > import the contenttype table which already exists. > > > 2nd Try: > > > 1. Dump data from old db using management command (dumpdata), > > > excluding the contenttype table (-e contenttypes) > > > 2. Drop DB and use django to create the database via syncdb > > > 3. Load data using management command on the new database > > > 4. Realize all data is completely useless since contenttype's PK's > > > are not connected to the same models as before. > > > 3rd Try: > > > 1. Dump data from old db using management command (dumpdata) > > > 2. Drop DB and use django to create the database via syncdb > > > 3. Truncate contenttype table > > > 4. Load data using management command on the new database > > > > > Possible solution that doesn't suck a lot: > > > I came up with quite a few different ways to handle this, but the best > > > so far (even thought it's not stellar) is to create a new column in > > > contenttypes that's a combined column. The combined column would > > > contain the app_label and model_name. > > > > > GenericForeignKey could use the combined column instead of the PK to > > > keep the references pointing to the same locations. I understand there > > > are some performance implications here, but it's the best I can come > > > up with. I would love to hear thoughts on this topic. > > > > I have run into this problem as well, and have come up with a basic > solution > > (for content types). The code is here:http://dpaste.com/119487/. It is > > implemented as a serializer, which you would plug into django, and then > use > > for serialization and deserialization of models with content types. > > > > It is rather simple (only about 10 lines of additional code). When it is > > dumping data, it checks to see if the field it is dumping is a content > type, > > and if so, it dumps a dictionary of app_label and model. Then, when this > > fixture is loaded back in, it runs a query against the Con
Re: Object Relational Mapping and REST Web Services in Django
On Thu, Feb 12, 2009 at 9:35 AM, wrote: > > Greetings Django Developers, > > Allow me to introduce myself; my name is Rory Tulk. I'm a grad > student at the University of Toronto. A small team of students and I > are investigating possible implications of unifying the process of > specifying object relational mapping configuration and URL & function > mapping for REST web services, and are intending on using Django as > our target platform for prototyping. As a starting point, I'd like to > elicit opinions from the community on directions this could go in. > Are there any feature requests outstanding for Django's ORM or Web > Service support? Any known pitfalls? > > Any input is greatly appreciated. > > --Rory Tulk > > > > Welcome Rory, This sounds like a neat project. I haven't done anything much like it, so I don't have any personal advice, but similar efforts have been attempted in the past. The django-rest-interface seems like a logical place to start, this was a google summer of code projects that Malcolm Tredinnick mentored: http://code.google.com/p/django-rest-interface/ Looking back through the history of django-dev will probably get you some of the design discussion that went on around this project. An example is: http://groups.google.com/group/django-developers/browse_thread/thread/a121b2ed850c93ab/d370133daeeb4b34?lnk=gst&q=rest+api#d370133daeeb4b34 Hope this helps to get your started. -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://ericholscher.com e...@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 -~--~~~~--~~--~--~---
1.1: Ticket #3569 (Enhanced Atom Support)
Hey all, I have talked to James Tauber about ticket #3569 which is about adding better support for Atom to the syndication feeds framework. He has suggested that if we want to include something along these lines in 1.1 that we should put it in Django along-side the current Atom support. He has a glue layer that maps the old API to his new (and improved) API[0], but it hasn't been well tested. I know a lot of people (myself included) use his atom.py[1] file instead of Django's atom feed framework. If we wanted to get better atom support in 1.1, I'm curious what people think of shipping two versions of a syndication feed API in this release. Jacob has marked the ticket as 1.1beta, so I'm assuming this means that it will be going into 1.1. So the question now becomes, what do we about the old syndication feed API. I know in the past it has been mentioned that it should be replaced by something better. It seems that #3569 is indeed something better. Should we also include the translation layer (that lets you use the old API with the new atom code), or just let people switch to the new API when ready? I think that including the new code in a place like django.contrib.atom would also be an option, for in the future there might be more support added for Atompub. There are also some questions about what happens to RSS in this setup, since it is not currently implemented in this new code. Curious what people think about these changes. There is no patch attached to the ticket, so trimming the code, adding docs, and perhaps adding a bit more testing[2] would be in order to have it included. I know James' has said that he would be willing to write it as a patch to Django, and I would also be willing to help do some legwork to get it committed. [0] http://code.google.com/p/django-atompub/source/browse/trunk/atompub/atom.py#475 [1] http://code.google.com/p/django-atompub/source/browse/trunk/atompub/atom.py [2] http://code.google.com/p/django-atompub/source/browse/trunk/atompub/test_validation.py Cheers, Eric --~--~-~--~~~---~--~~ 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: 1.2 Proposal: Add a few more tutorial steps
On Fri, Aug 7, 2009 at 10:05 PM, Russell Keith-Magee wrote: > > Add me to the same list. Initial drafting is always the painful bit > for me, but if someone wants to get some ideas together, I'm happy to > help edit, proofread, or give feedback. I think another good idea would be trying to incorporate some of the existing tutorials that are outside of the docs (on blogs and other resources), back in somehow. I don't know if this is an 'external links' type section, or asking people if adopting their content into the docs would be okay with them, and have them be part of the official docs. A few other ideas that haven't been explicitly mentioned, but are > probably worth a tutorial: > * Testing applications +1, been meaning to do this for a while. I have the beginnings on my blog, just need to get it into shape for the actual docs. So put me down for the 1.2 time frame on this one. Cheers, Eric --~--~-~--~~~---~--~~ 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: [Discussion] Legacy documentation / Boken docs Django v1.2
Happy to help with this. We can move the RTD builds to using Sphinx HTMLDir, and then redirects won't be necessary for the page titles, at least. On Thursday, February 18, 2016 at 12:58:03 PM UTC-4, Florian Apolloner wrote: > > > > On Thursday, February 18, 2016 at 4:24:09 PM UTC+1, Tim Graham wrote: >> >> I guess I'm not strongly opposed if someone wants to do that, but I don't >> think I can justify spending time on the DSF's dime to help out users of >> unsupported versions. >> > > +1 > -- 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/cf9fed8a-e41c-4f99-9326-2f17c0a18827%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
