Re: CacheManager
Ya cache invalidation is something you'll always have a problem with. The clean() method can be used (at the end of a queryset, or on the Manager itself) to force the invalidation. As for _get_sql_clause I guess I could make it just pull from filters/ extra args to build the key -- not as clean but it's the only other way I can think of. On Jul 4, 11:25 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > On 7/5/07, David Cramer <[EMAIL PROTECTED]> wrote: > > >http://www.davidcramer.net/code/50/django-cachemanager.html > > > Criticism welcomed! > > I think the order of bits returned from _get_sql_clause is dependent > on how the queryset is built up, so that you'll cache equivalent > result sets repeatedly. > > And there's the issue of cache invalidation. > > But definitely useful. --~--~-~--~~~---~--~~ 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: auto_now_add overwrites a given date
Hello, The question is, as I see it, what bad thing would happen if auto_now_add would set the date only if it's None. I think that nothing bad would happen - why should someone manually set the date and expect it to be overwritten? If you agree, I suggest that it will be changed, because I think that it would save other people hours of annoying debugging (it would have saved me hours of annoying debugging). I don't think that I'm especially stupid, so if it was unintuitive to me it may be unintuitive to others. What do you think? Noam --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Documentation should never show non-working examples. - was: "@cache_page" bug...
On 4 Jul., 09:51, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Wed, 2007-07-04 at 00:30 -0700, jedie wrote: > > "shortly"... But my "change docu" ticket is opened 2 weeks ago: > >http://code.djangoproject.com/ticket/4649 > > > The real bug is 2 years old and last modified 2 weeks ago, too: > >http://code.djangoproject.com/ticket/1015 > > Posts like this really encourage people to stop and help you, too. > > Have a look at what we've indicated is the correct fix for the problem > (#1015). Notice how the last comment on that ticket indicates what needs > to be done to get it finished? Directing your energies in that direction > would be a more productive use of time than posts like this. Sorry, you have misunderstood this. Thus I have not meant this. ;) Fixing the ticket #1015 is not important to me. The documentation philosophy is relevant for me: The documentation should really never show non-working examples. This is the point i mean and that is the question here. --~--~-~--~~~---~--~~ 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: Documentation should never show non-working examples. - was: "@cache_page" bug...
On Thu, 2007-07-05 at 00:39 -0700, jedie wrote: > On 4 Jul., 09:51, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-07-04 at 00:30 -0700, jedie wrote: > > > "shortly"... But my "change docu" ticket is opened 2 weeks ago: > > >http://code.djangoproject.com/ticket/4649 > > > > > The real bug is 2 years old and last modified 2 weeks ago, too: > > >http://code.djangoproject.com/ticket/1015 > > > > Posts like this really encourage people to stop and help you, too. > > > > Have a look at what we've indicated is the correct fix for the problem > > (#1015). Notice how the last comment on that ticket indicates what needs > > to be done to get it finished? Directing your energies in that direction > > would be a more productive use of time than posts like this. > > Sorry, you have misunderstood this. Thus I have not meant this. ;) > > Fixing the ticket #1015 is not important to me. > > The documentation philosophy is relevant for me: The documentation > should really never show non-working examples. Unsurprisingly, we are in 100% agreement. So if the documentation and the code are in disagreement, one of them has to be fixed. Fixing the code is the right thing in this case. Regards, Malcolm -- Everything is _not_ based on faith... take my word for it. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: auto_now_add overwrites a given date
On 7/5/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > It's a backwards-incompatible change, so we'd need a strong reason to > change it. [...] > This line of reasoning is unfortunately not particularly strong. The > problem is that one group of people might find the current behaviour of > something unintuitive. Another group might find the alternative verion > unintuitive and then there's no resolution. This is hypothetical. Do you have an example, or can you think of a situation, in which someone will set the field to some value and rely on Django to reset it to the current date? I can't think of a reason to do it. If I am correct, then: 1. There won't be a group that will find the current behaviour intuitive. 2. This isn't really backwards-incompatible, since there is no real code that depends on the current behaviour. And since I understand that Django's API is not yet "frozen", I think that it should be made the most intuitive, especially if it harms no real code. > In this particular case, I'll point out that the behaviour of > auto_now_add is clearly documented. It says that it is not a default you > can override. Similarly for auto_now. Well, I didn't read it, and it was counter-intuitive to me. I spend an hour or more on debugging, and, as I said, I don't think I'm especially stupid. I also don't think that users should be expected to read the entire documentation before using Django. Noam --~--~-~--~~~---~--~~ 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: auto_now_add overwrites a given date
On Thu, 2007-07-05 at 07:30 +, Noam wrote: > Hello, > > The question is, as I see it, what bad thing would happen if > auto_now_add would set the date only if it's None. It's a backwards-incompatible change, so we'd need a strong reason to change it. [...] > I think that it would save other people hours of > annoying debugging (it would have saved me hours of annoying > debugging). I don't think that I'm especially stupid, so if it was > unintuitive to me it may be unintuitive to others. This line of reasoning is unfortunately not particularly strong. The problem is that one group of people might find the current behaviour of something unintuitive. Another group might find the alternative verion unintuitive and then there's no resolution. In this particular case, I'll point out that the behaviour of auto_now_add is clearly documented. It says that it is not a default you can override. Similarly for auto_now. I'm -0.5 or so on changing this behaviour. Regards, Malcolm -- Save the whales. Collect the whole set. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: auto_now_add overwrites a given date
On Thu, 2007-07-05 at 10:52 +0300, Noam Raphael wrote: > On 7/5/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > It's a backwards-incompatible change, so we'd need a strong reason to > > change it. > [...] > > This line of reasoning is unfortunately not particularly strong. The > > problem is that one group of people might find the current behaviour of > > something unintuitive. Another group might find the alternative verion > > unintuitive and then there's no resolution. > > This is hypothetical. Do you have an example, or can you think of a > situation, in which someone will set the field to some value and rely > on Django to reset it to the current date? Form submission data for a form class created by form_for_model(). [...] > 2. This isn't really backwards-incompatible, since there is no real > code that depends on the current behaviour. There are thousands of users of Django. A claim like that is very hard to make. [...] > > In this particular case, I'll point out that the behaviour of > > auto_now_add is clearly documented. It says that it is not a default you > > can override. Similarly for auto_now. > > Well, I didn't read it, and it was counter-intuitive to me. I spend an > hour or more on debugging, and, as I said, I don't think I'm > especially stupid. I also don't think that users should be expected to > read the entire documentation before using Django. You're not being asked to read the entire documentation. You did have to read the models API to learn that auto_now_add existed in the first place. It is not really unreasonable to think that if somebody is having trouble making auto_now_add work, they will fairly quickly check the docs to make sure they are using it correctly. It's hardly an unusual work pattern that if something new you are doing does not work as expected, you check your assumptions. Best wishes, Malcolm -- I just got lost in thought. It was unfamiliar territory. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: Documentation should never show non-working examples. - was: "@cache_page" bug...
Malcolm Tredinnick skrev: > On Thu, 2007-07-05 at 00:39 -0700, jedie wrote: > >> The documentation philosophy is relevant for me: The documentation >> should really never show non-working examples. >> > > Unsurprisingly, we are in 100% agreement. So if the documentation and > the code are in disagreement, one of them has to be fixed. Fixing the > code is the right thing in this case. > You seem to be using different definitions of "never". Just saying. Nis --~--~-~--~~~---~--~~ 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: make db form settings
Carl Karsten skrev: > I have the begging of something that may eventually get submitted, and > looking > for guidance as I build it. > > In the spirit of DRY, I have a nifty script that helps create the db defined > in > settings.py > [snip] > I am thinking it would be nice if it was hung off of db/backends/mysql so > that > it was driven by DATABASE_ENGINE and the various backends could spit out the > appropriate dialect. > +1, I would use this. Also, don't we have this almost implemented for creating the test database? Nis --~--~-~--~~~---~--~~ 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: Documentation should never show non-working examples. - was: "@cache_page" bug...
jedie wrote: > Sorry, you have misunderstood this. Thus I have not meant this. ;) > > Fixing the ticket #1015 is not important to me. Insisting on telling people what to do, and not really doing anything yourself, is obnoxious. Please make a patch first, and then quibble, preferably in the ticket. -- I accuse you, Mr. Bush, [...] of fomenting fear among your own people, of creating the very terror you claim to have fought. -- Keith Olbermann, July 2007 --~--~-~--~~~---~--~~ 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: Documentation should never show non-working examples. - was: "@cache_page" bug...
On Thu, 2007-07-05 at 11:52 +0200, Nicola Larosa wrote: > jedie wrote: > > Sorry, you have misunderstood this. Thus I have not meant this. ;) > > > > Fixing the ticket #1015 is not important to me. > > Insisting on telling people what to do, and not really doing anything > yourself, is obnoxious. > > Please make a patch first, and then quibble, preferably in the ticket. This is all getting a bit unnecessarily heated (I'm far from innocent here, too, since I've let off steam in this thread). In an effort to restore order to the Force, I'm working on this right this minute. Hopefully that will make everybody happier and we can move onto having fun again. Thanks, Malcolm -- On the other hand, you have different fingers. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: auto_now_add overwrites a given date
On 7/5/07, Noam <[EMAIL PROTECTED]> wrote: > > The conclusion is that auto_now_add should set the date only if it is > None. Or, another solution: it should set the date upon instance > creation, not upon saving. FYI - this is a known problem, with scope and ramifications much larger than the problem you have identified. It also affects any model with a customized save() method, and is a major problem for accurate data serialization, which in turn is a problem for testing. The problem is logged as #4459; I'm hoping to spend some time fixing this in the near future. Neither of the solutions you propose are viable - as others have noted, the first is backwards incompatible, the second would make auto_now_add equivalent to auto_now. The best solution I can think of (and the solution that will probably get implemented, unless a better solution is proposed) is to add a 'preprocess=True' default argument to the save() method of a model. Default behaviour will be unaffected; however, if you call model.save(preprocess=False), Django will skip the pre-processing steps that modify dates and do other forms of database coercion. This will allow serialization to force a literal interpretation of input data, and would fix your problem as well. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: make db form settings
On 7/5/07, Nis Jørgensen <[EMAIL PROTECTED]> wrote: > > Carl Karsten skrev: > > I have the begging of something that may eventually get submitted, and > > looking > > for guidance as I build it. > > > > In the spirit of DRY, I have a nifty script that helps create the db > > defined in > > settings.py > > > [snip] > > I am thinking it would be nice if it was hung off of db/backends/mysql so > > that > > it was driven by DATABASE_ENGINE and the various backends could spit out the > > appropriate dialect. > > > > +1, I would use this. Also, don't we have this almost implemented for > creating the test database? Yes, but this technique relies upon being able to log into the normal database so as to make the CREATE DATABASE call as a native SQL request. You need to be able to log into a database (any database) to create another. This won't work for boostrapping the original database, unless you modify the Django setup to include settings for accessing the management database for each supported backend. For the record, I'm -1 to the idea. As Adrian has noted, database creation should be a relatively infrequent activity. Dropping/Creating a database isn't that difficult to do manually, and warrants being a _little bit_ difficult so as to make it difficult to accidentally drop a database with all the data in it (ie., you have to mentally swap to a 'database destruction mode' to do it, rather than just running another ./manage.py command). 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Documentation should never show non-working examples. - was: "@cache_page" bug...
On 5 Jul., 09:41, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Thu, 2007-07-05 at 00:39 -0700, jedie wrote: > > The documentation philosophy is relevant for me: The documentation > > should really never show non-working examples. > > Unsurprisingly,weare in100%agreement. So if the documentation and > the code are in disagreement, one of them has to be fixed. Fixing the > code is the right thing in this case. No, i thing we are not 100% agreement ;) I think: 1. The documentation should be changed, if there is a not working code example. (At least a node sould be inserted.) 2. Fix the bug and commit the pach. 3. Update the documentation again. (remove the obsolete note) You think: inset a note in the documentation is needless, because the bugfix patch would be shortly commit. IMHO: Bugs lived a long time in django, often :( It is not necessary to search non working example code every day or so. But if a user find a buggy example code and write a ticked like http://code.djangoproject.com/ticket/4649 , the documentation should be updated until the bug is not fixed. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSoC 2007 status update: Django package management (django-package)
Hi list,
This week I continued to work on the "startapp" command of
django.core.management and changed its default behaviour to create a
standalone application (with skeleton files) when you run: "django-
admin.py startapp myapp". Current skeleton files are: release.py,
setup.py, MANIFEST.in, docs/, test/, myapp/, myapp/templates/myapp.
Are there any generic files/folders to add?
Besides editing release.py manually you can now edit the meta
information by running inside an application dir: "django-admin.py
editapp". This also moves the app directory on a name change.
You can find a ReleaseWrapper dictionary object at
django.utils.package which can be used to read and edit your release
manually:
>> import os
>> from django.utils.package import ReleaseWrapper, DEFAULT_DIRECTORIES,
>> DEFAULT_FILES
>> release = ReleaseWrapper(os.getcwd())
>> print (release.NAME, release.VERSION)
('myapp', '0.1')
>> release.previous_name = release.NAME
>> release.NAME = "myapp2"
>> release['VERSION'] = "0.2"
>> release.update(os.getcwd(), DEFAULT_DIRECTORIES, DEFAULT_FILES)
Moved: /Users/Jannis/Desktop/test_app/myapp to /Users/Jannis/Desktop/
test_app/myapp2
Created: /Users/Jannis/Desktop/test_app/myapp2/templates/myapp2
Written: /Users/Jannis/Desktop/test_app/release.py
Written: /Users/Jannis/Desktop/test_app/setup.py
Written: /Users/Jannis/Desktop/test_app/MANIFEST.in
The application is ready to be used by setuptools, e.g. creating a zip-
like "egg" file ("python setup.py bdist_egg") which then can be
distributed and installed with setuptools' easy_install command.
Creating a stripped down project-based application (models.py,
views.py), which is currently recommended by the tutorials, run:
"django-admin.py --noskeleton startapp mysimpleapp"
Please have a look at http://code.google.com/p/django-package/ for
further details, full installation instructions and of course the
patch.
And please, tell me what you think :)
Best,
Jannis
--~--~-~--~~~---~--~~
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: make db form settings
Russell Keith-Magee wrote: > On 7/5/07, Nis Jørgensen <[EMAIL PROTECTED]> wrote: >> Carl Karsten skrev: >>> I have the begging of something that may eventually get submitted, and >>> looking >>> for guidance as I build it. >>> >>> In the spirit of DRY, I have a nifty script that helps create the db >>> defined in >>> settings.py >>> >> [snip] >>> I am thinking it would be nice if it was hung off of db/backends/mysql so >>> that >>> it was driven by DATABASE_ENGINE and the various backends could spit out the >>> appropriate dialect. >>> >> +1, I would use this. Also, don't we have this almost implemented for >> creating the test database? > > Yes, but this technique relies upon being able to log into the normal > database so as to make the CREATE DATABASE call as a native SQL > request. You need to be able to log into a database (any database) to > create another. This won't work for boostrapping the original > database, unless you modify the Django setup to include settings for > accessing the management database for each supported backend. > > For the record, I'm -1 to the idea. As Adrian has noted, database > creation should be a relatively infrequent activity. Dropping/Creating > a database isn't that difficult to do manually, What part of creating a web site is? This whole django thing is pretty pointless. :) > and warrants being a > _little bit_ difficult so as to make it difficult to accidentally drop > a database with all the data in it (ie., you have to mentally swap to > a 'database destruction mode' to do it, rather than just running > another ./manage.py command). For that, I'll # out the DROP command. Carl K --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
Yes, I understand that. But does that mean that it's developed in 2.3, 2.4 and 2.5 or just one of those? I know this is a weird question, but I'm doing research for work and need to know this info. The fact that it's just compatible with versions greater than 2.3 is not enough - I need to know the exact version of Python the Django code is written in. Thanks, Anna On Jul 5, 10:19 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > > > Can anyone tell me what version of Python the latest version of Django > > (and previous versions if available) is written/developed in? Or can > > you tell me where I can find that info? > > Django is compatible with any version of Python greater than 2.3, as > noted in the Django installation documentation: > > http://www.djangoproject.com/documentation/install/ > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
please help! need to know python version
Hi all, Can anyone tell me what version of Python the latest version of Django (and previous versions if available) is written/developed in? Or can you tell me where I can find that info? Thanks, Anna --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > Can anyone tell me what version of Python the latest version of Django > (and previous versions if available) is written/developed in? Or can > you tell me where I can find that info? Django is compatible with any version of Python greater than 2.3, as noted in the Django installation documentation: http://www.djangoproject.com/documentation/install/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
Ok, thanks. That's the answer I was afraid of, unfortunately. Just in case anyone knows, is it the same with the other frameworks for Python, like Pylons, Turbogears, etc? I'm thinking yes, based on your answers here, but just wondering. Thanks again, Anna On Jul 5, 10:42 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > > > > > On Jul 5, 10:19 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > > > On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > > > > > Can anyone tell me what version of Python the latest version of Django > > > > (and previous versions if available) is written/developed in? Or can > > > > you tell me where I can find that info? > > > > Django is compatible with any version of Python greater than 2.3, as > > > noted in the Django installation documentation: > > > >http://www.djangoproject.com/documentation/install/ > > > Yes, I understand that. But does that mean that it's developed in > > 2.3, 2.4 and 2.5 or just one of those? I know this is a weird > > question, but I'm doing research for work and need to know this info. > > The fact that it's just compatible with versions greater than 2.3 is > > not enough - I need to know the exact version of Python the Django > > code is written in. > > I think you're asking an unanswerable question; Django is developed > *against* a particular minimum Python version's specification. > Someone could, in theory, hack on Django without ever touching a > Python interpreter (although I'd hope not, since running the test > suite is a Good Thing). ^_^ What version used alongside development > to test things will differ from developer to developer. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > Yes, I understand that. But does that mean that it's developed in > 2.3, 2.4 and 2.5 or just one of those? I know this is a weird > question, but I'm doing research for work and need to know this info. > The fact that it's just compatible with versions greater than 2.3 is > not enough - I need to know the exact version of Python the Django > code is written in. There is no "one version" in which Django is developed; different developers have different installations with different versions of Python, much the same as one developer might be writing code on Linux, another on a Mac and yet another on a Windows machine (or, in a Windows shop, one might have Vista, one XP and one Win2k). We check compatibility by carefully reviewing the code and by running the test suite against all three versions of Python we support (similarly, we check database support by running the test suite against all of the available database backends). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > On Jul 5, 10:19 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > > On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > > > > > Can anyone tell me what version of Python the latest version of Django > > > (and previous versions if available) is written/developed in? Or can > > > you tell me where I can find that info? > > > > Django is compatible with any version of Python greater than 2.3, as > > noted in the Django installation documentation: > > > > http://www.djangoproject.com/documentation/install/ > > Yes, I understand that. But does that mean that it's developed in > 2.3, 2.4 and 2.5 or just one of those? I know this is a weird > question, but I'm doing research for work and need to know this info. > The fact that it's just compatible with versions greater than 2.3 is > not enough - I need to know the exact version of Python the Django > code is written in. I think you're asking an unanswerable question; Django is developed *against* a particular minimum Python version's specification. Someone could, in theory, hack on Django without ever touching a Python interpreter (although I'd hope not, since running the test suite is a Good Thing). ^_^ What version used alongside development to test things will differ from developer to developer. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
runtests failures
I'm slowly getting this a bit more readable, but I won't post duplicates.
Carl K
Updated to revision 5620.
./runtests.py --settings settings_sqlite 2>&1|tee --append runtests.log
./runtests.py --settings settings_mysql 2>&1|tee --append runtests.log
sqlite (failures=2)
mysql (failures=5)
==
FAIL: An assertion is raised if the response redirects to another target
--
Traceback (most recent call last):
File
"/home/carl/django/django-src/tests/regressiontests/test_client_regress/models.py",
line 82, in test_incorrect_target
self.assertEquals(str(e), "Response didn't redirect as expected: Reponse
code was 301 (expected 302)")
AssertionError: "Response didn't redirect as expected: Response code was 301
(expected 302)" != "Response didn't redirect as expected: Reponse code was 301
(expected 302)"
==
FAIL: An assertion is raised if the original page couldn't be retrieved as
expected
--
Traceback (most recent call last):
File
"/home/carl/django/django-src/tests/regressiontests/test_client_regress/models.py",
line 73, in test_redirect_page
self.assertEquals(str(e), "Response didn't redirect as expected: Reponse
code was 301 (expected 302)")
AssertionError: "Response didn't redirect as expected: Response code was 301
(expected 302)" != "Response didn't redirect as expected: Reponse code was 301
(expected 302)"
--
Ran 139 tests in 59.513s
FAILED (failures=2)
/usr/lib/python2.5/site-packages/django/db/models/base.py:247: Warning:
Incorrect string value: '\xE6\x9E\x97\xE5\x8E\x9F...' for column 'headline' at
row 1
','.join(placeholders)), db_values)
==
FAIL: Doctest: modeltests.basic.models.__test__.API_TESTS
--
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/django/test/_doctest.py", line 2161,
in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
modeltests.basic.models.__test__.API_TESTS
File "/home/carl/django/django-src/tests/modeltests/basic/models.py", line
unknown line number, in API_TESTS
--
File "/home/carl/django/django-src/tests/modeltests/basic/models.py", line ?,
in
modeltests.basic.models.__test__.API_TESTS
Failed example:
Article.objects.get(pk=a.id).headline
Expected:
u'\u6797\u539f \u3081\u3050\u307f'
Got:
u'?? ???'
==
FAIL: Doctest: modeltests.fixtures.models.__test__.API_TESTS
--
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/django/test/_doctest.py", line 2161,
in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
modeltests.fixtures.models.__test__.API_TESTS
File "/home/carl/django/django-src/tests/modeltests/fixtures/models.py",
line
unknown line number, in API_TESTS
--
File "/home/carl/django/django-src/tests/modeltests/fixtures/models.py", line
?,
in modeltests.fixtures.models.__test__.API_TESTS
Failed example:
Article.objects.all()
Expected:
[, , ]
Got:
[, , , ]
--
File "/home/carl/django/django-src/tests/modeltests/fixtures/models.py", line
?,
in modeltests.fixtures.models.__test__.API_TESTS
Failed example:
print management.dump_data(['fixtures'], format='json')
Expected:
[{"pk": "3", "model": "fixtures.article", "fields": {"headline": "Time to
reform copyright", "pub_date": "2006-06-16 13:00:00"}}, {"pk": "2", "model":
"fixtures.article", "fields": {"headline": "Poker has no place on ESPN",
"pub_date": "2006-06-16 12:00:00"}}, {"pk": "1", "model": "fixtures.article",
"fields": {"headline": "Python program becomes self aware", "pub_date":
"2006-06-16 11:00:00"}}]
Got:
[{"pk": "5", "model": "fixtures.article", "fields": {"headline": "XML
identified as leading cause of cancer", "pub_date": "2006-06-16 16:00:00"}},
{"pk": "3", "model": "fixtures.article", "fields": {"headline": "Time to reform
copyright", "pub_date": "2006-06-16 13:00:00"}}, {"pk": "2", "model":
"fixtures.article", "fields": {"headline": "Poker on TV is great!", "pub_date":
"2006-06-16 11:00:00"}}, {"pk": "1", "model": "fixtures.article", "fields":
{"headline": "Python program becomes self aware", "pub_date": "2006-0
Re: please help! need to know python version
I think you may want to /join #python on irc or somehting, because there really wasn't an answer given, so not sure what answer you think you got. Python code is not developed in Python. that can be debated, but for the purposed of this thread, I think it fits. That is like asking "what kind of car was your car developed in?" cars are designed in offices, built in factories, driven on roads. granted software development is a bit more integrated, it is also still separate. maybe a better example would be "what brand of monitor was used?" It would help if you explained the "research for work." Carl K anna wrote: > Ok, thanks. That's the answer I was afraid of, unfortunately. > > Just in case anyone knows, is it the same with the other frameworks > for Python, like Pylons, Turbogears, etc? I'm thinking yes, based on > your answers here, but just wondering. > > Thanks again, > Anna > > On Jul 5, 10:42 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote: >> On 7/5/07, anna <[EMAIL PROTECTED]> wrote: >> >> >> >>> On Jul 5, 10:19 am, "James Bennett" <[EMAIL PROTECTED]> wrote: On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > Can anyone tell me what version of Python the latest version of Django > (and previous versions if available) is written/developed in? Or can > you tell me where I can find that info? Django is compatible with any version of Python greater than 2.3, as noted in the Django installation documentation: http://www.djangoproject.com/documentation/install/ >>> Yes, I understand that. But does that mean that it's developed in >>> 2.3, 2.4 and 2.5 or just one of those? I know this is a weird >>> question, but I'm doing research for work and need to know this info. >>> The fact that it's just compatible with versions greater than 2.3 is >>> not enough - I need to know the exact version of Python the Django >>> code is written in. >> I think you're asking an unanswerable question; Django is developed >> *against* a particular minimum Python version's specification. >> Someone could, in theory, hack on Django without ever touching a >> Python interpreter (although I'd hope not, since running the test >> suite is a Good Thing). ^_^ What version used alongside development >> to test things will differ from developer to developer. > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > Just in case anyone knows, is it the same with the other frameworks > for Python, like Pylons, Turbogears, etc? I'm thinking yes, based on > your answers here, but just wondering. In the Python world, developing "against" a single specific version of the language tends to be frowned upon; there's quite a lot of code out there which runs compatibly on versions of Python from 1.5 through 2.5, and comparatively very little which is tied to a single specific version of Python. Web framworks that I've seen tend to be upwards compatible from 2.3 or 2.4, while in general a lot of Python software aims for compatibility from 2.2 or 2.4, depending on what features they need. Is there a reason why you were hoping Django would somehow "favor" a single specific version? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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: CacheManager
On 7/5/07, David Cramer <[EMAIL PROTECTED]> wrote: > So I had a cool little idea -- to build a CacheManager, which let our > team collaborate with caching controls and not duplicating data in the > cache. > > So, here's a rough draft that i hammered out in 15 minutes. > > http://www.davidcramer.net/code/50/django-cachemanager.html Oooh, this is something I've wanted to do for ages...See http://code.djangoproject.com/ticket/5 , which was marked as wontfix by Jacob (but I'd still like to see this feature). Some feedback: * I'd suggest making "key_prefix" and "expire" actual arguments to CacheManager.__init__() rather than assuming they're in kwargs. That way, you can set defaults in the normal way, and you get the normal Python required-argument functionality (i.e., Python will complain if you don't pass the argument). * Same goes for CachedQuerySet.__init__(). * As Jeremy pointed out, there's no guaranteed order for the result of _get_sql_clause(). You might want to order the contents of _get_sql_clause() explicitly (alphabetically, or something), so you get consistent cache keys. Coincidentally (or not), this is the original non-starter that prevented me from working on this feature myself a year or two ago. :-) * This might be out of the scope of this code, but it might be worth allowing the client code to set the expire time at runtime somehow, not just when instantiating CacheManager. * CachedQuerySet.clean() is missing a "self" in its function definition. I'm looking forward to seeing how this matures -- thanks to you and your team for writing it, David! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > > Ok, thanks. That's the answer I was afraid of, unfortunately. > > Just in case anyone knows, is it the same with the other frameworks > for Python, like Pylons, Turbogears, etc? Yes. Why is the answer unfortunate? The answer is not bad-- the question just has some bad assumptions built into it. Python is not compiled until deployment, and compatibility on minor revs is very good. How is it useful to know exactly which version something is if the deployed code is plain text run in a compatible interpreter? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
Why is that unfortunate? It's just that Django is compatible with Python versions 2.3, 2.4 and 2.5. I would have thought that was a good thing. It just means that you can install any of the above versions of Python with the latest version of Django and it will all work. You would need to look at the other projects to get specific information, but most of them are compatible with more than one version of Python. Regards, Gary. anna wrote: > Ok, thanks. That's the answer I was afraid of, unfortunately. > > Just in case anyone knows, is it the same with the other frameworks > for Python, like Pylons, Turbogears, etc? I'm thinking yes, based on > your answers here, but just wondering. > > Thanks again, > Anna > > On Jul 5, 10:42 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote: >> On 7/5/07, anna <[EMAIL PROTECTED]> wrote: >> >> >> >>> On Jul 5, 10:19 am, "James Bennett" <[EMAIL PROTECTED]> wrote: On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > Can anyone tell me what version of Python the latest version of Django > (and previous versions if available) is written/developed in? Or can > you tell me where I can find that info? Django is compatible with any version of Python greater than 2.3, as noted in the Django installation documentation: http://www.djangoproject.com/documentation/install/ >>> Yes, I understand that. But does that mean that it's developed in >>> 2.3, 2.4 and 2.5 or just one of those? I know this is a weird >>> question, but I'm doing research for work and need to know this info. >>> The fact that it's just compatible with versions greater than 2.3 is >>> not enough - I need to know the exact version of Python the Django >>> code is written in. >> I think you're asking an unanswerable question; Django is developed >> *against* a particular minimum Python version's specification. >> Someone could, in theory, hack on Django without ever touching a >> Python interpreter (although I'd hope not, since running the test >> suite is a Good Thing). ^_^ What version used alongside development >> to test things will differ from developer to developer. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > > On Jul 5, 10:42 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > > > > I think you're asking an unanswerable question; Django is developed > > *against* a particular minimum Python version's specification. > > Someone could, in theory, hack on Django without ever touching a > > Python interpreter (although I'd hope not, since running the test > > suite is a Good Thing). ^_^ What version used alongside development > > to test things will differ from developer to developer. > > Ok, thanks. That's the answer I was afraid of, unfortunately. > > Just in case anyone knows, is it the same with the other frameworks > for Python, like Pylons, Turbogears, etc? I'm thinking yes, based on > your answers here, but just wondering. Why is that answer troubling? I have the feeling there's a misunderstanding going on here regarding what you're trying to discover, and for what purpose. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
On Jul 5, 2007, at 10:19 AM, James Bennett wrote: > Django is compatible with any version of Python greater than 2.3, as > noted in the Django installation documentation: > > http://www.djangoproject.com/documentation/install/ You mean >=, right? :-) Don --~--~-~--~~~---~--~~ 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: CacheManager
On 7/5/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > Oooh, this is something I've wanted to do for ages...See > http://code.djangoproject.com/ticket/5 , which was marked as wontfix > by Jacob (but I'd still like to see this feature). I'd also be interested to get input from the SoC student who's working on (somewhat) similar stuff; if the two projects can cross-pollinate ideas with each other, it'd be nice not to have to worry about multiple competing implementations when the time comes ;) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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: CacheManager
On 7/5/07, David Cramer <[EMAIL PROTECTED]> wrote: > > Ya cache invalidation is something you'll always have a problem with. > The clean() method can be used (at the end of a queryset, or on the > Manager itself) to force the invalidation. We have been working on this issue recently and came up with a mechanism that solves this problem for us - when creating a cache, we register with a CacheInvalidator object a model, test and a cache key. CacheInvalidator than listens for post_save signals and for every model check the registered tests... if a test passes, the cache_key associated with the test is deleted. So if you can construct a test based on the QuerySet's filters etc, you will be able to invalidate just the querysets actually affected by the change... We haven't tested it for performance (we are building a high-volume site) yet and we still haven't figured out how to deal with multiple web servers connecting to one cache (our working version includes propagating the post_save signal via some asynchronous communication channel like apache's ActiveMQ, but we might end up with a separate server just for the cache invalidation). Is anybody interested in this? > As for _get_sql_clause I guess I could make it just pull from filters/ > extra args to build the key -- not as clean but it's the only other > way I can think of. > > On Jul 4, 11:25 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > > On 7/5/07, David Cramer <[EMAIL PROTECTED]> wrote: > > > > >http://www.davidcramer.net/code/50/django-cachemanager.html > > > > > Criticism welcomed! > > > > I think the order of bits returned from _get_sql_clause is dependent > > on how the queryset is built up, so that you'll cache equivalent > > result sets repeatedly. > > > > And there's the issue of cache invalidation. > > > > But definitely useful. > > > > > -- Honza Kr�l E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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: make db form settings
I recently made a patch that can be used to get a similar result.
You can find the patch here: http://code.djangoproject.com/ticket/4528
regards,
Johan Bergström
On Jul 4, 7:54 pm, Carl Karsten <[EMAIL PROTECTED]> wrote:
> I have the begging of something that may eventually get submitted, and looking
> for guidance as I build it.
>
> In the spirit of DRY, I have a nifty script that helps create the db defined
> in
> settings.py
>
> #!/usr/bin/env python
> # mkdbuser.py
> # prints the CREATE DATABASE and GRANT commands based on the local settings.py
>
> import settings
>
> SQL = """
> DROP DATABASE IF EXISTS %(db)s;
> CREATE DATABASE %(db)s;
> GRANT ALL
> ON %(db)s.*
> TO %(user)s
> IDENTIFIED BY '%(pw)s'
> with grant option;
>
> """
>
> print SQL % {
> 'db':settings.DATABASE_NAME,
> 'user':settings.DATABASE_USER,
> 'pw':settings.DATABASE_PASSWORD }
>
> # end: mkdbuser.py
>
> I pipe it into the client:
> $ ./mkdbuser.py | mysql -u root -p
> and presto! I have the db that syncdb wants.
>
> I am thinking it would be nice if it was hung off of db/backends/mysql so that
> it was driven by DATABASE_ENGINE and the various backends could spit out the
> appropriate dialect.
>
> I am also researching exactly what rights are needed by syncdb and runserver
> or
> any production use so that what is spit out isn't quite so wide open. If
> anyone
> has already done this, I would rather not repeat it. :) however, if someone
> wants me to anyway so we can compare notes to make sure we didn't mis
> anything,
> thats fine too.
>
> Carl K
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: please help! need to know python version
It's complicated to explain, but basically, anything that goes onto our systems must be approved and only certain versions of Python are approved for use/development (2.4 and possibly earlier ones, but I'm not sure). We haven't yet chosen a framework to use for development and it would be easier to get something approved if it was developed against version(s) of Python already approved for our systems. On Jul 5, 11:19 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > > > Just in case anyone knows, is it the same with the other frameworks > > for Python, like Pylons, Turbogears, etc? I'm thinking yes, based on > > your answers here, but just wondering. > > In the Python world, developing "against" a single specific version of > the language tends to be frowned upon; there's quite a lot of code out > there which runs compatibly on versions of Python from 1.5 through > 2.5, and comparatively very little which is tied to a single specific > version of Python. Web framworks that I've seen tend to be upwards > compatible from 2.3 or 2.4, while in general a lot of Python software > aims for compatibility from 2.2 or 2.4, depending on what features > they need. > > Is there a reason why you were hoping Django would somehow "favor" a > single specific version? > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > > On Jul 5, 11:19 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > > > > In the Python world, developing "against" a single specific version of > > the language tends to be frowned upon; there's quite a lot of code out > > there which runs compatibly on versions of Python from 1.5 through > > 2.5, and comparatively very little which is tied to a single specific > > version of Python. Web framworks that I've seen tend to be upwards > > compatible from 2.3 or 2.4, while in general a lot of Python software > > aims for compatibility from 2.2 or 2.4, depending on what features > > they need. > > > > Is there a reason why you were hoping Django would somehow "favor" a > > single specific version? > > It's complicated to explain, but basically, anything that goes onto > our systems must be approved and only certain versions of Python are > approved for use/development (2.4 and possibly earlier ones, but I'm > not sure). We haven't yet chosen a framework to use for development > and it would be easier to get something approved if it was developed > against version(s) of Python already approved for our systems. Django is made to work with Python 2.3 *and later*, as stated earlier in this thread. If your organization uses Python 2.4, you won't have a problem. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > It's complicated to explain, but basically, anything that goes onto > our systems must be approved and only certain versions of Python are > approved for use/development (2.4 and possibly earlier ones, but I'm > not sure). We haven't yet chosen a framework to use for development > and it would be easier to get something approved if it was developed > against version(s) of Python already approved for our systems. Then you have no problems here; Django will work on Python 2.4. In a larger sense, it seems like you're confused about the Python language; different versions of Python generally have good compatibility with each other, which means that you don't have to rewrite or recompile (in fact, you never "compile" Python code) when moving between supported versions (e.g., you could "upgrade" or "downgrade" your Python version without needing to change anything). This is why we say Django is not developed "against" any single version of Python -- because Python does a good job of maintaining compatibility between versions, Django can run on any of Python 2.3, 2.4 or 2.5 without modification (and again, the Django test suite verifies this). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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: CacheManager
Sorry, new link: http://dpaste.com/hold/13668/ On Jul 5, 11:41 am, "Honza Král" <[EMAIL PROTECTED]> wrote: > On 7/5/07, David Cramer <[EMAIL PROTECTED]> wrote: > > > > > Ya cache invalidation is something you'll always have a problem with. > > The clean() method can be used (at the end of a queryset, or on the > > Manager itself) to force the invalidation. > > We have been working on this issue recently and came up with a > mechanism that solves this problem for us - when creating a cache, we > register with a CacheInvalidator object a model, test and a cache key. > CacheInvalidator than listens for post_save signals and for every > model check the registered tests... if a test passes, the cache_key > associated with the test is deleted. So if you can construct a test > based on the QuerySet's filters etc, you will be able to invalidate > just the querysets actually affected by the change... > > We haven't tested it for performance (we are building a high-volume > site) yet and we still haven't figured out how to deal with multiple > web servers connecting to one cache (our working version includes > propagating the post_save signal via some asynchronous communication > channel like apache's ActiveMQ, but we might end up with a separate > server just for the cache invalidation). > > Is anybody interested in this? > > > > > As for _get_sql_clause I guess I could make it just pull from filters/ > > extra args to build the key -- not as clean but it's the only other > > way I can think of. > > > On Jul 4, 11:25 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > > > On 7/5/07, David Cramer <[EMAIL PROTECTED]> wrote: > > > > >http://www.davidcramer.net/code/50/django-cachemanager.html > > > > > Criticism welcomed! > > > > I think the order of bits returned from _get_sql_clause is dependent > > > on how the queryset is built up, so that you'll cache equivalent > > > result sets repeatedly. > > > > And there's the issue of cache invalidation. > > > > But definitely useful. > > -- > Honza Kr?l > E-Mail: [EMAIL PROTECTED] > ICQ#: 107471613 > Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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: CacheManager
On 7/5/07, Honza Král <[EMAIL PROTECTED]> wrote: > We haven't tested it for performance (we are building a high-volume > site) yet and we still haven't figured out how to deal with multiple > web servers connecting to one cache (our working version includes > propagating the post_save signal via some asynchronous communication > channel like apache's ActiveMQ, but we might end up with a separate > server just for the cache invalidation). FWIW, on the memcached list right now, they're writing agenda for an upcoming hackathon. Regex-based key purging is on the drawing board. That sounds nuts, but Brad is a genius. The proposed approach is to have any mass delete not actually delete immediately, but increment a generation counter. Any get on a key with an older generation would then be tested newer generation delete patterns and matching keys would be expired at that time. You might go see if you could use that and contribute to it if so. > Is anybody interested in this? Yes indeed. I'm going to be building something fairly high-volume and low-latency, and am trying to come up with an efficient way of mass invalidation, too. --~--~-~--~~~---~--~~ 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: auto_now_add overwrites a given date
Thanks! Ok, I see that the problem is more complicated than I thought, so I'll leave it that way. I just want to add that if you decide that you don't like the current behaviour, you can always use FutureWarning, to first warn if a value was set and is about to be discarded, and then change the behaviour. Have a good day, Noam On 7/5/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 7/5/07, Noam <[EMAIL PROTECTED]> wrote: > > > > The conclusion is that auto_now_add should set the date only if it is > > None. Or, another solution: it should set the date upon instance > > creation, not upon saving. > > FYI - this is a known problem, with scope and ramifications much > larger than the problem you have identified. It also affects any model > with a customized save() method, and is a major problem for accurate > data serialization, which in turn is a problem for testing. > > The problem is logged as #4459; I'm hoping to spend some time fixing > this in the near future. > > Neither of the solutions you propose are viable - as others have > noted, the first is backwards incompatible, the second would make > auto_now_add equivalent to auto_now. > > The best solution I can think of (and the solution that will probably > get implemented, unless a better solution is proposed) is to add a > 'preprocess=True' default argument to the save() method of a model. > Default behaviour will be unaffected; however, if you call > model.save(preprocess=False), Django will skip the pre-processing > steps that modify dates and do other forms of database coercion. This > will allow serialization to force a literal interpretation of input > data, and would fix your problem as well. > > 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
GSoC Update: [Check Constraints] Testing and some regular stuff
Hello Django Developers, After the Oracle branch got merged into trunk, the django check constraints patch code had broken. So I had to fix it (just a one line change). Also this week I decided to test the work with databases like SQLite and Oracle. It worked perfectly with SQLite but there is a small issue with Oracle. The issue is with Oracle's date field which uses an unconventional format. I will work on it later but currently am writing doctests for the Check Class. The Google Code Hosting page for Django Check Constraints now contains a test django project with test apps, readme and install files. Also screenshots (mainly for those Mac users who could not view my screencasts). I was wondering if I should move all the SQL creation code from management.py to within the SQL Class itself (ie by overriding the __str__ method. So the SQL code is printed out everytime the __str__ method is called.). Please help resolve this confusion. The project hosting page is at http://code.google.com/p/django-check-constraints Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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: Documentation should never show non-working examples. - was: "@cache_page" bug...
imo, the official documentation should not document bugs, and should also not provide non-working examples. therefore either the bug should be fixed immediately, or the example should be removed immediately (to be re-instated when the bug is fixed). it is true that many bugs remain in trunk for a long time, either at design decision needed or even accepted. if there are fairly substantial long-standing bugs that get a lot of questions and many people spend time debugging over and over again, could there be a "known issues" page (referring back to the tickets) that people can check first? or is this also a wasted effort, and people should just search the tickets directly? --~--~-~--~~~---~--~~ 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: runtests failures
On Thu, 2007-07-05 at 12:50 -0500, Carl Karsten wrote:
> I'm slowly getting this a bit more readable, but I won't post duplicates.
Are you asking for help diagnosing these or trying to report a bug?
You've just posted a bunch of output here without any surrounding text,
so it's a bit hard to work out if a response is needed/expected.
>
> Carl K
>
> Updated to revision 5620.
>
> ./runtests.py --settings settings_sqlite 2>&1|tee --append runtests.log
> ./runtests.py --settings settings_mysql 2>&1|tee --append runtests.log
>
> sqlite (failures=2)
> mysql (failures=5)
The failures shown up by the SQLite are fixed in 5621.
Russell is not allowed to go sky-diving for a week as punishment for
making that mistake.
Some of the MySQL ones are expected, as has been mentioned in threads
here recently. Others -- all the encoding-related ones -- look like you
might need to set TEST_DATABASE_CHARSET ('utf8' is a good value) or you
aren't using MySQL-python-1.2.1p2 or later (even 1.2.1c3 is too early)
or you are using the mysql_old backend.
Regards,
Malcolm
--
He who laughs last thinks slowest.
http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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: runtests failures
On 7/6/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > The failures shown up by the SQLite are fixed in 5621. > > Russell is not allowed to go sky-diving for a week as punishment for > making that mistake. Oh. balls. One of these days I'll remember that there ain't no such thing as a trivial fix. Apologies to all for that stuff up. Russ %-) --~--~-~--~~~---~--~~ 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: runtests failures
Malcolm Tredinnick wrote:
> On Thu, 2007-07-05 at 12:50 -0500, Carl Karsten wrote:
>> I'm slowly getting this a bit more readable, but I won't post duplicates.
>
> Are you asking for help diagnosing these or trying to report a bug?
> You've just posted a bunch of output here without any surrounding text,
> so it's a bit hard to work out if a response is needed/expected.
sorry, meant to clarify, and ... didn't.
I think I am just reporting, but there is a good chance I am creating my own
problems - pretty new at the django thing.
I started running the tests when I was having trouble re-building a site I had
cobbled together, and when I tried to organize things I started getting errors,
so I ran the django tests hoping it wasn't my fault. (turns out I had moved a
dir named calendar into the path, and presto! new calendar module!)
>
>
>> Carl K
>>
>> Updated to revision 5620.
>>
>> ./runtests.py --settings settings_sqlite 2>&1|tee --append runtests.log
>> ./runtests.py --settings settings_mysql 2>&1|tee --append runtests.log
>>
>> sqlite (failures=2)
>> mysql (failures=5)
>
> The failures shown up by the SQLite are fixed in 5621.
yup
svnversion 5621
Ran 139 tests in 58.875s
OK
>
> Russell is not allowed to go sky-diving for a week as punishment for
> making that mistake.
hold back one of his shoots. I'm sure the other one will work. (hope it isn't
in bad taste to make jokes about something I don't really know anything about.)
>
> Some of the MySQL ones are expected, as has been mentioned in threads
> here recently. Others -- all the encoding-related ones -- look like you
> might need to set TEST_DATABASE_CHARSET ('utf8' is a good value) or you
> aren't using MySQL-python-1.2.1p2 or later (even 1.2.1c3 is too early)
>
Um... 1p2? does p come before, after, or on top of 'final'?
django/db/backends/mysql/base.py
# We want version (1, 2, 1, 'final', 2) or later. We can't just use
>>> import MySQLdb
>>> MySQLdb.version_info
(1, 2, 1, 'final', 2)
Either I have a good ver, or the test for version needs to be updated?
> or you are using the mysql_old backend.
just to be sure:
[EMAIL PROTECTED]:~/django/django-src/tests$ cd ../django/db/backends/
[EMAIL PROTECTED]:~/django/django-src/django/db/backends$ rm -rf mysql_old/
and I am assuming this defines whcih it uses:
DATABASE_ENGINE = 'mysql'
./runtests.py --settings settings_mysql
Got an error creating the test database: (1007, "Can't create database 'django_t
est_db'; database exists")
It seems stuck there? perhaps I should mysql> drop database django_test_db;
but that should never be done, right? :)
hmm, dropped, runtests running, getting the expected errors now.
FAILED (failures=3)
rats, just blew away the log testing the "Can't create database" = "stuck" bug,
but I'm guessing you are aware of them.
"Can't create database" = "stuck" bug:
mysql> create database django_test_db;
Query OK, 1 row affected (0.00 sec)
./runtests.py --settings settings_mysql
Got an error creating the test database: (1007, "Can't create database
'django_test_db'; database exists")
and there it sits, well over 5x as long as it takes to run when it doesn't get
that error. I am going to let it sit while I sleep, but you may want to take a
peek, cuz even if it does do something in the next 8 hours, it still seems odd.
Carl K
--~--~-~--~~~---~--~~
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: runtests failures
On Fri, 2007-07-06 at 01:21 -0500, Carl Karsten wrote:
> Malcolm Tredinnick wrote:
[...]
> >
> > Some of the MySQL ones are expected, as has been mentioned in threads
> > here recently. Others -- all the encoding-related ones -- look like you
> > might need to set TEST_DATABASE_CHARSET ('utf8' is a good value) or you
> > aren't using MySQL-python-1.2.1p2 or later (even 1.2.1c3 is too early)
> >
>
> Um... 1p2? does p come before, after, or on top of 'final'?
>
> django/db/backends/mysql/base.py
> # We want version (1, 2, 1, 'final', 2) or later. We can't just use
>
> >>> import MySQLdb
> >>> MySQLdb.version_info
> (1, 2, 1, 'final', 2)
No, that's 1.2.1p2. The "1.2.1p2" is the version on the released
package, but version_info reports as you have indicated above. So you're
fine there.
>
> Either I have a good ver, or the test for version needs to be updated?
>
> > or you are using the mysql_old backend.
>
> just to be sure:
> [EMAIL PROTECTED]:~/django/django-src/tests$ cd ../django/db/backends/
> [EMAIL PROTECTED]:~/django/django-src/django/db/backends$ rm -rf mysql_old/
>
> and I am assuming this defines whcih it uses:
> DATABASE_ENGINE = 'mysql'
>
> ./runtests.py --settings settings_mysql
>
> Got an error creating the test database: (1007, "Can't create database
> 'django_t
> est_db'; database exists")
>
> It seems stuck there? perhaps I should mysql> drop database django_test_db;
> but that should never be done, right? :)
It will be asking you if you want to drop the database. If you are
redirecting stdout/stderr, then you aren't seeing that question. Just
let it run and output to the terminal. We don't blow away databases
without asking; that would be dangerous.
Here is what happens when I try it with an existing database (settings1
is my mysql settings file):
`--> ./runtests.py --settings=settings1
Got an error creating the test database: (1007, "Can't create
database 'django_test_db'; database exists")
It appears the test database, django_test_db, already exists.
Type 'yes' to delete it, or 'no' to cancel:
At that point I have to type "yes" to continue.
>
> hmm, dropped, runtests running, getting the expected errors now.
>
> FAILED (failures=3)
All going smoothly there should be only only one failed test:
modeltests.fixtures (two sub-tests in there fail because the default
MySQL storage engine does not support transactions, but it's reported as
"failures=1").
Regards,
Malcolm
--
Why can't you be a non-conformist like everyone else?
http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
