Re: Is this group moderated, or is it a bug with google groups?
On Sun, Jan 28, 2007 at 08:19:33AM +0530, Kenneth Gonsalves wrote: > > > On 26-Jan-07, at 12:19 PM, medhat wrote: > > > So many times I send messages to the group, but my message does not > > appear at all, or it might appear a day or two after I actually send > > it, which of course makes it appear down on the list, and nobody > > really > > sees it. > > not moderated - and no bug in googlegroups either. There must be some > obstruction between your mailserver and google. I had similar problems myself with django-users. Messages appearing up to 36-40 hours later and messages never arrived to the list. sandro *;-) -- Sandro Dentella *:-) http://www.tksql.orgTkSQL Home page - My GPL work --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple Django on Apache
On Tue, Feb 06, 2007 at 12:18:45PM -0800, Moses Ting wrote: > > Hello, > > I've been having ALOT of trouble getting multiple Django instances to > work on one machine. This is a local machine and I'm trying to set up > a dev and a test instance of Django. The problem is that when I try > to access the dev site via http://machine:90, it still brings up the > test version of django. Any help would be much appreciated... > > I have the following lines in the Apache httpd conf file. Aren't you just missing 'PythonInterpreter a_name'? If you need to put two Django installations within the same VirtualHost, you'll need to take a special precaution to ensure mod_python's cache doesn't mess things up. Use the PythonInterpreter directive to give different directives separate interpreters: ... The values of PythonInterpreter don't really matter, as long as they're different between the two Location blocks. *:-) > > #= > # Test Site > #= > > NameVirtualHost *:80 > > > ServerName machine:80 > DocumentRoot "C:/myproject/test/www" > > > Options Indexes FollowSymLinks > AllowOverride None > Order allow,deny > Allow from all > > > > SetHandler python-program > PythonPath "['c:/myproject/test/site'] + sys.path" > PythonHandler django.core.handlers.modpython > SetEnv DJANGO_SETTINGS_MODULE haltnet_site.settings > PythonDebug On > PythonAutoReload On > > > SetHandler None > > > SetHandler None > > > -- Sandro Dentella *:-) e-mail: [EMAIL PROTECTED] http://www.tksql.orgTkSQL Home page - My GPL work --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #3297newforms: Implement FileField and ImageField
On Tue, Feb 20, 2007 at 06:14:34PM -, [EMAIL PROTECTED] wrote: > > Could someone review this ticket? I started using it last week. I /really, really/ needed it and it seems to work fine in a version of create_update working with newforms, so that I use it both with form_for_model and form_for_instance. What is the testing you think you need? I'd be glad to give feedback so that it can be pushed into svn. sandro *:-) -- Sandro Dentella *:-) http://www.tksql.orgTkSQL Home page - My GPL work --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
FloatField, blank and newforms and PostgreSQL failure
I'd like to take your attention on a side effect of missing FloatField.formfield(): CharField is used in newforms that means that null=True, blank=True will use an empty strings that correctly makes PostgreSql quite angry... (sqlite doesn't bother...) Digging into the open tickets I see the reason is that there is a "design decision" to be taken wheather to use decimals or floats (how can a FloatField be mapped into a decimal.decimal...). Ticket 2365 shows the issue: http://code.djangoproject.com/ticket/2365 If we really want to push newform I see that these kind of problems must be solved pretty soon. back in a while with new issues... sandro *:-) PS: i really appreciate the work that is being done and working with django is a real pleasure... ;-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
many_to_many, symmetry and newforms
Here again... Im trying to understand if there is a real need to brake symmetry in a ManyToMany relation, and how can that be bypassed creating a model. Let's use User/Group models. class User(model.Model): ... groups = models.ManyToManyField(Group,...) creating a form using form_for_models I get a nice widget(*) created to select groups to which the user belongs. The reverse is not true, you don't get a widget for the user in the form created for Group. Why that? The tecnical reason is that form_for_model has a loop as this: for f in model._meta.fields + model._meta.many_to_many: ... and mode._meta.many_to_may is not symmetrycally filled, of course I could get the list using model._meta.get_all_related_many_to_many_objects() but I think I miss the reason of the difference between many_to_many attribute and method output, so that I don't know if the way to go should be to fix the attribute to have complete information (as I would think) or to change form_for_model to use the get_all... method. [Anoter solution is to write the definition in both models, using db_table, but that will make syncdb complain the table already exits, when tries to create the middle table for the second time...] sandro *:-) (*) not really, that was true with oldforms, now you must define a formfield_callback... -- Sandro Dentella *:-) http://www.tksql.orgTkSQL Home page - My GPL work --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Constraints and MySQL
On Tue, Feb 27, 2007 at 11:26:11AM -0600, Jacob Kaplan-Moss wrote: > > On 2/27/07, Seattle Daniel <[EMAIL PROTECTED]> wrote: > > As I read it, there is not a way to force InnoDB to check constraints > > at commit. And once there is it will be quite some time before the > > mass of MySQL instances support it. > > So... I think that leaves is with two kinda sucky choices: > > 1. Revert [4610] so that all databases work the same way, and not > allow forward references in serializers (or elsewhere). > > 2. Leave [4610] in, and not allow forward references in MySQL. > > I'd suggest #1 for orthogonality, but does anyone else have any ideas? Why should a limit of a db impact on the others? If MySQL cannot do something that PostgreSQL can do, that's a reason to be taken into account when choosing the backend. *:-) --~--~-~--~~~---~--~~ 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: Upcoming Django release, and the future
On Mon, Feb 26, 2007 at 06:16:31PM -, [EMAIL PROTECTED] wrote: > > I would like to see http://code.djangoproject.com/ticket/3297 > implemented before 0.96 if possible. I definitely agree. And more It's a working one! I think that newforms are the true change in this releise. We need to try the out with at least all the features that where present with oldform. One more missing brick is a floatfield. How can you use it without float field? A decision must be taken on Decimals/Floats. I don't really care, I use python2.4 but I *need* a float field and a numeric one, and as I already told to this list, FloatField.formfield() is missing so that postgresql will just (correctly) refuse to insert an empty string into the db. I see that also in the user list people have asked for this. Again: a patch is already present and working. sandro *:-) --~--~-~--~~~---~--~~ 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: signals
> The problem is that there is a userbase of thousands and a lot of > evidence to suggest that most people don't read mailing list threads > that they didn't start themselves. Yes, almost everybody reading this is so let's come to the surface... i use signals. Mainly pre-save / post-save. And just to let you know I miss a post_insert different from post_update. sandro *:-) --~--~-~--~~~---~--~~ 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: Time for a new release?
> Our philosophy so far has been that documentation improvements are > something that *all* current Django users should benefit from, > including users of trunk *and* users of the latest release. If we find > typos, or we take the time to write up better explanations of things, > we want to have that positive effect on as many users as possible. > Hence, we point people by default at the very latest versions of the > docs, because they have the latest and greatest stuff. > > But the problem isn't with the documentation improvements, of course > -- those don't confuse people (we hope!). The problem is with the > parts of the documentation that are specific to the Django development > version. Traditionally, we've been marking these with the text "New in > Django development version" -- as long as we remember to do this. This > has worked well, IMHO, except in the case of the recent "max_length" > vs "maxlength" change, in which the documentation *was* uniformly > updated to use "max_length" but didn't actually mention anything about > the fact that it had only changed in trunk! > > I should stress that, if we continue down this path of pointing people > at the trunk documentation by default, all documentation changes that > refer to new trunk features *must* be written in a way that users of > 0.96 will understand the change does not apply to them. We need to do > a better job of telling contributors and documentation writers that > this is how we do things. While I completely agree on what you say, I'd point out that not only differences from 0.96 to trunk should be noted, if possible, but also between svn versions following latest release. As an example when test.clinet.login changed I've been puzzled by the different syntax between the docs and te code, no mention in the docs, probably just becouse no test.client was present in 0.96 (just guessing). Even those who try to follow trunk have to stop on a release for a while but being informed on the development of the syntax may also be a real incentive to update. Sometimes just an icon that warns you about diffrences between releases would be sufficent, better would be the link to the explanation. I think in any case that even people that stick to latest stable release should read svn docs: sooner or later they will need to update, better to be aware of new syntax! sandro *:-) PS: A last note related to docs but not really on this specific issue: it'd be nice to have a rss feed on changes in docs. I know it's very easy to make a script to have that using svn diff. I just mean that it's probably a general interest thing. --~--~-~--~~~---~--~~ 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: Time for a new release?
On Sun, Aug 26, 2007 at 04:47:28AM -0500, James Bennett wrote: > > On 8/26/07, Sandro Dentella <[EMAIL PROTECTED]> wrote: > > While I completely agree on what you say, I'd point out that not only > > differences from 0.96 to trunk should be noted, if possible, but also > > between svn versions following latest release. As an example when > > test.clinet.login changed I've been puzzled by the different syntax between > > the docs and te code, no mention in the docs, probably just becouse no > > test.client was present in 0.96 (just guessing). > > We already document changes which break compatibility between releases > (on the wiki because it's easier to keep updated there): > > http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges > > If you're tracking SVN, at the very least you need to watch that page. I know and I read that page regularly. Can I suggest we put an icon in the docs in any places where something that has backword incompatible issues that links to the BackwordIncompatibleChanges page? sandro *:-) --~--~-~--~~~---~--~~ 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: I18n seems not to work with mod_wsgi
On Sat, Sep 29, 2007 at 08:01:12PM -0700, [EMAIL PROTECTED] wrote: > > Doh, it was not mod_wsgi, or localemiddleware, it was the > set_language_view() that after rev 6177 requires a post request I see in the Backwards-incompatible changes says: The old behaviour meant that state (the locale used to display the site) could be changed by a GET request, which is against the HTTP specification's recommendations. I'm no expert of these specifications and would like to better understand. Firstly I'd appreciate a link to relevant part, secondly, reading the follow-up in the backward incompatible changes is: This means you can no longer use a link to access the view, but must use a form submission of some kind (e.g. a button). Isn't this just making it (a little bit) more difficult to obtain the same thing? My (admittedly ignorant) point of view was simply that modification of data should be done via a POST not just the state. If I implemented traslations with different URLs (mysite/en|it/...) if would be ok to use GET but not if I use sessions? sorry if this becomes a little bit OT... sandro *:-) --~--~-~--~~~---~--~~ 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 breaks Python 2.5's help()
On Wed, Oct 10, 2007 at 07:41:14AM -, Tomi Pieviläinen wrote: > > It seems that if you have Django installed for Python 2.5, the > internal help system breaks up a bit. To reproduce just open the > normal shell (not through manage.py), type "help()" and "modules". > > Setting DJANGO_SETTINGS_MODULE works around this, but shouldn't IMO be > required. Also 2.4 works just fine (don't have 2.3 anymore). Both 0.96 > and HEAD have the same symptoms. you can't even use tab completion of modules from inside ipython if you have django installed. Again becouse of DJANGO_SETTINGS_MODULE settings. sandro --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
