Re: Translation corrections
On Mon, Jul 21, 2008 at 12:45 AM, diogobaeder <[EMAIL PROTECTED]> wrote: > > Hi! > Hi, I'm Brazilian too. > > I'm willing to start contributing to Django, already, but in a field > that will not be hard for me to understand, and in which I can be more > usefull: the Brazillian-Portuguese translation package. I'd like to > propose some corrections in it, since I'm Brazillian and do not agree > with some terms and phrases used in it. > That's great. I think that you can contribut in the translate project for the Django documentation to portuguese. For more informations, see the group (http://groups.google.com/group/django-l10n-portuguese) and the repository (http://code.google.com/p/django-l10n-portuguese/) about this project. There are a group for brazilians djangonauts too. The group is a http://groups.google.com/group/django-brasil and website is http://djangobrasil.org Thanks! -- Andrews Medina www.andrewsmedina.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: Is URL template tag's syntax going to change?
I'm also +1 for the change (and in fact, for any change that we would
regret not having done after 1.0 goes live). To back this up, the
above note has been hanging in the documentation for several months
(more than 8, as far as I can track back), so people could not say
that they weren't warned.
Over the last couple of weeks there's been lots of backward
incompatibilities introduced in trunk, so that would only be a small
extra one, and one that's easy to overcome.
On Jul 21, 4:55 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Johannes Dollinger wrote:
> > Afaics the only other tag that would accept an arbitrary unquoted
> > literal is {% ssi %}.
> > Are there more?
>
> Actually when I've first implemented {% url %} I looked for formatting
> parameters at {% cycle %}. Which back then had only one syntax:
>
> {% cycle val1,val2,val3 %}
>
> ... where values were treated literally. No {% cycle %} has a more
> proper syntax in addition to the old one. Unfortunately there's, as I
> see, no way to do the same thing for {% url %}.
>
> Having said that I'm actually +1 for the change. We're breaking a lot of
> code on the road to 1.0 so nobody will notice such a small change :-)
--~--~-~--~~~---~--~~
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: Is URL template tag's syntax going to change?
Johannes Dollinger wrote:
> Afaics the only other tag that would accept an arbitrary unquoted
> literal is {% ssi %}.
> Are there more?
Actually when I've first implemented {% url %} I looked for formatting
parameters at {% cycle %}. Which back then had only one syntax:
{% cycle val1,val2,val3 %}
... where values were treated literally. No {% cycle %} has a more
proper syntax in addition to the old one. Unfortunately there's, as I
see, no way to do the same thing for {% url %}.
Having said that I'm actually +1 for the change. We're breaking a lot of
code on the road to 1.0 so nobody will notice such a small change :-)
--~--~-~--~~~---~--~~
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: Translation corrections
Thanks a lot, guys! I'm looking forward to make my move into helping Django to evolve! :-) See ya! Diogo On Jul 21, 3:26 am, "Andrews Medina" <[EMAIL PROTECTED]> wrote: > On Mon, Jul 21, 2008 at 12:45 AM, diogobaeder <[EMAIL PROTECTED]> wrote: > > > Hi! > > Hi, > > I'm Brazilian too. > > > > > I'm willing to start contributing to Django, already, but in a field > > that will not be hard for me to understand, and in which I can be more > > usefull: the Brazillian-Portuguese translation package. I'd like to > > propose some corrections in it, since I'm Brazillian and do not agree > > with some terms and phrases used in it. > > That's great. I think that you can contribut in the translate project > for the Django documentation to portuguese. For more informations, see > the group (http://groups.google.com/group/django-l10n-portuguese) and > the repository (http://code.google.com/p/django-l10n-portuguese/) > about this project. > > There are a group for brazilians djangonauts too. The group is > ahttp://groups.google.com/group/django-brasiland website > ishttp://djangobrasil.org > > Thanks! > > -- > Andrews Medinawww.andrewsmedina.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 -~--~~~~--~~--~--~---
SCRIPT_NAME/PATH_INFO, etc, changes
In [8015] I finally landed the patch to fix a number of issue with URL parsing that we've been talking about. It explicitly fixes #285, #1516 and #3414, but possibly others as well, and is based on a patch that John Melesky wrote at a sprint last year (although I forgot to thank him in the commit message because I'm an idiot). However, due the nature of the change it may contain subtle issues. I've tested it as carefully as I can on Apache + fastcgi, Apache + modwsgi, Apache + mod_python, CherryPy's server, lighttpd + fastcgi, but I'm really tired right now, so something may have slipped past as I ironed out all the problems. The main reason I'm posting here is because this will cause confusion for people, so if everybody on this list could help out with explanations and keep an eye out, that would be appreciated. Also, I struggled to write the documentation coherently, mostly because I'm tired, so feel free to straighten things out (I just noticed I've forgotten to include Apache + modwsgi on the backwards-incompat page, but screw it ... I'll fix that tomorrow if nobody does it earlier. It's straightforward). Finally, I'd appreciate new tickets being opened for these problems, rather than reopening the existing ones (people will reopen the existing ones, which is fair enough, but I'd like to move them to separate tickets). The original tickets have become a watering hole for all sorts of approaches to the problem and aren't really about the final solution. It will be easier to address the concrete problems that come up as a result of this with new tickets. Regards, Malcolm --~--~-~--~~~---~--~~ 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: #7611 contrib.auth PasswordResetTest requires specific templates for tests to pass
> However, if the user is _not_ using the views (e.g., they're using the
> auth.User model, but providing their own login views), there is an
> argument to be made for skipping the tests.
Is it safe to say that if we try to
reverse('django.contrib.auth.views.password_reset'), we should not run
the tests? This would negate the use of urls that was introduced in
#7521. The patch you submitted for loading test templates in #7611
seems to complement the use of urls from #7521 in TestCase. I feel it
should be both or none. In the latter case, we should simply skip the
test case if django.contrib.auth.views.password_reset is not used.
--~--~-~--~~~---~--~~
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: Problems with concurrent DB access and get_or_create()
Hi, I'm using rev 7713 (I need to port to the new upload handling before I can get back to trunk). The code that actually adds to the table: def do_update(self, event): if event.countable: matrix, new = self.get_or_create(date=event.time.date(), member=event.target, shop=event.shop, product=event.product) matrix.increment_column(event.type) matrix.save() Ben On Jul 16, 3:28 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > What version are you running, and what's the exact line you're using > for get_or_create? --~--~-~--~~~---~--~~ 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: #7611 contrib.auth PasswordResetTest requires specific templates for tests to pass
On Sat, Jul 19, 2008 at 1:58 PM, Jason Yan <[EMAIL PROTECTED]> wrote: > > Re: http://code.djangoproject.com/ticket/7611 > > The current situation is that if you create a new Django project and > run the unit tests, the contrib.auth baisc tests fail due to missing > templates. These templates are provided by the admin app, which is > not installed by default. Russell brought up some points which made > me think about this more. My initial implementation was to force the > inclusion of the admin app if it wasn't already installed, but I agree > with Russell's initial comment that it isn't testing for the presence > of the admin app. > > I believe that we should not run these tests if we cannot find the > templates for the same reason we don't run Docutils tests if docutils > is not installed. Though the error reported that the template is not > found is "correct", I don't believe it is a correct test failure > because that is not the goal of the test case. I disagree. Like I say in the comment for the ticket, you can't claim that the auth application works correctly in your project if those templates are not available. The comparison with docutils tests is slightly off target. There is an argument to me made for skipping those tests - but not because we can't find the templates. Failing due to the non-existence of the templates is a legitimate failure if the user is actually using the views. However, if the user is _not_ using the views (e.g., they're using the auth.User model, but providing their own login views), there is an argument to be made for skipping the tests. There could actually be an overlap here with #4788 - that ticket calls for a mechanism to skip and report tests that are known and acceptable failures. Providing a project-level way to skip tests that are known failures could be one solution to both problems. 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: Is URL template tag's syntax going to change?
Johannes Dollinger wrote: > Of course that's subjective, everything is. You're in the wrong line of work, man... ;-) -- Nicola Larosa - http://www.tekNico.net/ --~--~-~--~~~---~--~~ 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: SCRIPT_NAME/PATH_INFO, etc, changes
First of all, thank you very much to Malcolm for fixing this - clearly
a massive step forwards towards 1.0!
I've subsequently had a discussion on the #3414 ticket tracker, which
I'm now moving to django-developers before it becomes too lengthy, as
per the "How to contribute".
The question is how Django should handle cases when PATH_INFO is not
set in the environment with which WSGI is called. The options are:
1) These are unusual cases, so Django should not handle this - "well,
then, don't configure your server that way".
2) If PATH_INFO is missing, Django should attempt to generate it from
other environment variables that may be present (e.g. REQUEST_URI).
Current behaviour is 1. I'd like to change to behaviour 2, since it
can't hurt - these cases just fail under behaviour 1 - and it will
succeed in some cases.
I've come across two cases in which PATH_INFO is not set:
1) SCGI + Cherokee (according to early discussion on #3414)
2) FastCGI + Lighttpd in an unusual configuration described on #3414
(this configuration was disliked by several commentators, but does
mirror the standard Rails + Lighttpd config at
http://github.com/rails/rails/tree/master/railties/configs/lighttpd.conf)
There are probably more cases with other webservers/configurations.
The patch to change to behaviour 2 is simple and self-contained. I
attach a version against [8015] below.
What do people think? I also have a similar patch for missing
QUERY_STRING when that should be there but isn't.
Richard.
--- a/django/core/handlers/wsgi.py(revision 8015)
+++ b/django/core/handlers/wsgi.py(working copy)
@@ -76,7 +76,10 @@
class WSGIRequest(http.HttpRequest):
def __init__(self, environ):
script_name = base.get_script_name(environ)
-path_info = force_unicode(environ.get('PATH_INFO', '/'))
+if environ.has_key('PATH_INFO') and environ['PATH_INFO']:
+path_info = force_unicode(environ['PATH_INFO'])
+else:
+path_info = force_unicode(environ.get('REQUEST_URI',
'/').partition('?')[0])
self.environ = environ
self.path_info = path_info
self.path = '%s%s' % (script_name, path_info)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Admin validation
Hi, is there any reason at all for a formset used in edit inline to be subclass of BaseModelFormSet aside from ease of use? We currently have a few instances where we do not want the individual forms to correspond 1to1 to model instances and this checks does not make any sense in that case. Could we please move the validation out of admin to ./manage.py validate_admin or something? I really want to be able to develop without having to hack django (to disable validation) of have DEBUG = False in my settings. This is a feature I don't think belongs to runtime (even when only used when DEBUG). Any thoughts? thanks 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 -~--~~~~--~~--~--~---
Last call for 1.0 alpha
Hi folks -- Well, with #285 fixed (thanks, Malcolm!) we're looking pretty good to release 1.0 alpha later today. Time-wise I think the plan is to do the release late this afternoon (CST), but that's really up to James. There's still a few tickets open in the 1.0 alpha milestone (http://code.djangoproject.com/milestone/1.0%20alpha); I'm eyed them and they're all stuff that we indeed need to fix before we open the release. Of them, only #7825 has me really stumped, so if someone else can look at that and try to figure anything else, I'd be really grateful. If there's anything that absolutely *MUST* be in 1.0 alpha, speak up now. Please keep in mind that the alpha release is intended only for the "must-have" features, which are now all in. This means that the only things that should hold up the release are serious blockers -- things that would prevent substantial numbers of users from successfully using Django. Jacob [If you happen to be at OSCON I'll be working on 1.0 alpha on the lower floor over by the Starbucks if you wanna come over and help out.] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Last call for 1.0 alpha
On Mon, Jul 21, 2008 at 11:18 AM, Jacob Kaplan-Moss < [EMAIL PROTECTED]> wrote: > If there's anything that absolutely *MUST* be in 1.0 alpha, speak up > now. Please keep in mind that the alpha release is intended only for > the "must-have" features, which are now all in. This means that the > only things that should hold up the release are serious blockers -- > things that would prevent substantial numbers of users from > successfully using Django. > I think it would be good if #7414 was fixed for alpha. The bug prevents correct install (data files are put in the wrong place) on OS X 10.5, and thus gives a bad first impression of Django, on what I think is a pretty important platform. It's got a patch, specific to that platform so it should be harmless on non-Macs. Getting it in sooner rather than later would help ensure this annoying issue that's cropped up a couple of times on different platforms is well and truly fixed with this patch for OS X. Karen --~--~-~--~~~---~--~~ 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: Last call for 1.0 alpha
Jacob Kaplan-Moss wrote: > [If you happen to be at OSCON I'll be working on 1.0 alpha on the > lower floor over by the Starbucks if you wanna come over and help > out.] I'm not at OSCON, but I can take care of #7864 (docs renaming), as I've got a patch already in the works. Gary --~--~-~--~~~---~--~~ 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: Last call for 1.0 alpha
On Mon, Jul 21, 2008 at 8:48 AM, Karen Tracey <[EMAIL PROTECTED]> wrote: > I think it would be good if #7414 was fixed for alpha. Good call. I'm on 10.5 here so I can test it and get it done. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Last call for 1.0 alpha
On Mon, Jul 21, 2008 at 8:48 AM, Gary Wilson Jr. <[EMAIL PROTECTED]> wrote: > I'm not at OSCON, but I can take care of #7864 (docs renaming), as I've > got a patch already in the works. Cool - go ahead and check that in; I'll give it a quick skim-over but doc fixes are easily done a bit after if we need to. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Last call for 1.0 alpha
On Mon, Jul 21, 2008 at 11:37 AM, Tom Tobin <[EMAIL PROTECTED]> wrote: > Gah, I really haven't had time to do the > move-code-out-of-__init__-modules dance. I'm fairly certain that > it'll be completely backwards compatible (via re-importing back into > __init__), though, so I'm not too worried; I got a tad anxious about > it a couple of weeks back, but I can't come up with a scenario that > would break existing code. I certainly hope 1.0 alpha isn't about hitting the backwards-compatible limit yet, because if it is, #5361 has failed to make the cut in time. The way I understand it, we still have some time to introduce mild incompatibilities in 1.0 beta, when it'll hit a hard freeze. jacob, is this correct? -Gul --~--~-~--~~~---~--~~ 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: Last call for 1.0 alpha
On Jul 21, 12:04 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > Are you saying these JUST started failing for MySQL? This True/1 False/0 > issue has been known for a while (http://code.djangoproject.com/ticket/7190 > ). Wow...I'm on a roll today, lol. Somehow I didn't manage to find that one in my searches. Thanks, Karen. I see that 7190 is not attached to a milestone. Where in the roadmap do we foresee "All tests passing" as a requirement? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Installing alpha over 96.x?
I just tried installing current svn (via setup.py) on a machine where I had previously installed 0.96.2. Install works but I notice that there are files (contrib/admin/urls.py, contrib/admin/utils.py are two I knew to check for) that used to exist in the old version but have been deleted in current -- these files are still present in the django directory under site-packages after installing current on top of 0.96.2. Might these leftover files cause a problem? I fear we are going to run into mutant problems with leftover files like this. Should we document somewhere how people who have previously installed a release should delete the old release before installing a new one? Longer term, could setup.py be enhanced to recognize a previously installed release and blow it away before installing the new code (I know next to nothing about the capabilities of Python's setup/install support)? Karen --~--~-~--~~~---~--~~ 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: Installing alpha over 96.x?
On Jul 21, 2008, at 12:17 PM, Karen Tracey wrote: > I just tried installing current svn (via setup.py) on a machine > where I had previously installed 0.96.2. Install works but I notice > that there are files (contrib/admin/urls.py, contrib/admin/utils.py > are two I knew to check for) that used to exist in the old version > but have been deleted in current -- these files are still present in > the django directory under site-packages after installing current on > top of 0.96.2. > > Might these leftover files cause a problem? I fear we are going to > run into mutant problems with leftover files like this. > django/admin/urls.py can lead to some difficult to debug migrations. utils.py I wouldn't worry about, but if we are at it trying to get rid of one, mind as well do both. > Should we document somewhere how people who have previously > installed a release should delete the old release before installing > a new one? Whatever it would take to remove those would be really ideal. Brian Rosner http://oebfare.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: Installing alpha over 96.x?
On Mon, Jul 21, 2008 at 3:17 PM, Karen Tracey <[EMAIL PROTECTED]> wrote: > I just tried installing current svn (via setup.py) on a machine where I had > previously installed 0.96.2. Install works but I notice that there are > files (contrib/admin/urls.py, contrib/admin/utils.py are two I knew to check > for) that used to exist in the old version but have been deleted in current > -- these files are still present in the django directory under site-packages > after installing current on top of 0.96.2. > > Might these leftover files cause a problem? I fear we are going to run into > mutant problems with leftover files like this. > > Should we document somewhere how people who have previously installed a > release should delete the old release before installing a new one? > Isn't this already documented?, or do you think these instrunction aren't comprehensive enough?: http://www.djangoproject.com/documentation/install/#remove-any-old-versions-of-django Regards, -- Ramiro Morales --~--~-~--~~~---~--~~ 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: Table Row count: Limiting factor
On Mon, 2008-07-21 at 08:13 -0700, madhav wrote: > Hello guys, I am just confused with a fundamental db problem. I have > table which has got 48 lakh rows(each row has got 8 fields, all > INDEXED) and I just need to fetch 500 rows from it. Would that take > more time than extracting the same number(500) of rows from a small > table of say 1 Lakh rows? Each row field is indexed in both the cases. > Please correct me if I am wrong. This sort of question is more appropriate for django-users than here. It's also something you should test for yourself on your real data. The best way to work out a performance question is to time it. Malcolm --~--~-~--~~~---~--~~ 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: Last call for 1.0 alpha
I've opened #7867 for regressiontests.model_inheritance_regress failures against MySQL. I've marked it 1.0 beta for now, but depending on requirements of the test suite passing before tagging a release. it may need to reassigned. It looks like a mix-up of True/1 and False/0, but I havent really looked at it in much depth. And sorry about the mix-up on #7741...it was late and I realized the docs didn't get updated, so being a bit tired I decided to take the bath of least resistance :-) --~--~-~--~~~---~--~~ 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: Last call for 1.0 alpha
On Mon, Jul 21, 2008 at 10:18 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > If there's anything that absolutely *MUST* be in 1.0 alpha, speak up > now. Please keep in mind that the alpha release is intended only for > the "must-have" features, which are now all in. This means that the > only things that should hold up the release are serious blockers -- > things that would prevent substantial numbers of users from > successfully using Django. Gah, I really haven't had time to do the move-code-out-of-__init__-modules dance. I'm fairly certain that it'll be completely backwards compatible (via re-importing back into __init__), though, so I'm not too worried; I got a tad anxious about it a couple of weeks back, but I can't come up with a scenario that would break existing code. --~--~-~--~~~---~--~~ 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: Installing alpha over 96.x?
On Mon, Jul 21, 2008 at 2:28 PM, Ramiro Morales <[EMAIL PROTECTED]> wrote: > > On Mon, Jul 21, 2008 at 3:17 PM, Karen Tracey <[EMAIL PROTECTED]> wrote: > > I just tried installing current svn (via setup.py) on a machine where I > had > > previously installed 0.96.2. Install works but I notice that there are > > files (contrib/admin/urls.py, contrib/admin/utils.py are two I knew to > check > > for) that used to exist in the old version but have been deleted in > current > > -- these files are still present in the django directory under > site-packages > > after installing current on top of 0.96.2. > > > > Might these leftover files cause a problem? I fear we are going to run > into > > mutant problems with leftover files like this. > > > > Should we document somewhere how people who have previously installed a > > release should delete the old release before installing a new one? > > > > Isn't this already documented?, or do you think these instrunction aren't > comprehensive enough?: > > > http://www.djangoproject.com/documentation/install/#remove-any-old-versions-of-django > > Those are good. Unfortunately I fear they may be missed. If you follow the "Download latest release" link on the home page to here: http://www.djangoproject.com/download/ the "Get latest official version" takes you through calling setup.py install without mentioning first deleting any previous version. There is a pointer at the bottom to the more detailed page that has the note about deleting old code, but one might easily skip it by just following the earlier instructions. Just want to suggest that whatever notes go with the alpha download include deleting old code first, if installing on top of an old release. Karen --~--~-~--~~~---~--~~ 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: SCRIPT_NAME/PATH_INFO, etc, changes
On Mon, Jul 21, 2008 at 7:54 AM, Richard Davies <[EMAIL PROTECTED]> wrote: > The question is how Django should handle cases when PATH_INFO is not > set in the environment with which WSGI is called. The options are: >From the WSGI spec: """ environ Variables [...] The following variables **must** be present, unless their value would be an empty string, in which case they may be omitted, except as otherwise noted below. [...] PATH_INFO [...] This may be an empty string, if the request URL targets the application root [...] """ By my reading, this clearly indicates that if the server doesn't set PATH_INFO, the server is broken. I'm not inclined to handle this any more than I'm inclined to support OS/2. Jacob [The OS/2 reference is a bit of an inside joke; sorry :)] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
django sites subframework confusing
Hi all- I am having a very hard time tracking down some detailed documentation on the sites subframework. I have read the django book and gone through the tutorial. I've also read the Sites documentation page. I find the documentations page provides the most details to the uses of the subframework, but I have not found any practical guides to implementing Sites. Specifically, I'm trying to understand how I would run multiple sites using one Django instance. Sites seams to satisfy that need; but as I understand it, you then need to have a different settings file for each site, which I believe would require a djange instance running for each site. Am I wrong? Can anybody show point me to a tutorial or paste some code that shows their settings.py for the one or multiple Django instances? Thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Last call for 1.0 alpha
On Mon, Jul 21, 2008 at 12:57 PM, Chris Hasenpflug < [EMAIL PROTECTED]> wrote: > > I've opened #7867 for regressiontests.model_inheritance_regress > failures against MySQL. I've marked it 1.0 beta for now, but > depending on requirements of the test suite passing before tagging a > release. it may need to reassigned. It looks like a mix-up of True/1 > and False/0, but I havent really looked at it in much depth. > Are you saying these JUST started failing for MySQL? This True/1 False/0 issue has been known for a while (http://code.djangoproject.com/ticket/7190 ). Karen --~--~-~--~~~---~--~~ 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 sites subframework confusing
On Mon, 2008-07-21 at 20:27 -0700, Trent wrote: > Hi all- > > I am having a very hard time tracking down some detailed documentation > on the sites subframework. I have read the django book and gone > through the tutorial. I've also read the Sites documentation page. I > find the documentations page provides the most details to the uses of > the subframework, but I have not found any practical guides to > implementing Sites. > > Specifically, I'm trying to understand how I would run multiple sites > using one Django instance. Sites seams to satisfy that need; but as I > understand it, you then need to have a different settings file for > each site, which I believe would require a djange instance running for > each site. Am I wrong? Can anybody show point me to a tutorial or > paste some code that shows their settings.py for the one or multiple > Django instances? This is really a better question for the django-users mailing list. This list is more concerned with the development of django internals. So please take any follow-ups over there. The short version is that the sites framework is for running the same code against the same database in different installations (i.e. different settings files). The sort of thing you're searching for isn't possible out of the box for a few technical reasons. Basically, it's one "Location" (in Apache-speak) per settings file, if you like. Regards, Malcolm --~--~-~--~~~---~--~~ 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: Last call for 1.0 alpha
On Mon, Jul 21, 2008 at 10:49 AM, Marty Alchin <[EMAIL PROTECTED]> wrote: > I certainly hope 1.0 alpha isn't about hitting the > backwards-compatible limit yet, because if it is, #5361 has failed to > make the cut in time. The way I understand it, we still have some time > to introduce mild incompatibilities in 1.0 beta, when it'll hit a hard > freeze. jacob, is this correct? >From the wiki VersionOneRoadmap: # There's a larger set of "maybe" features: if these features are done by the 1.0 feature-freeze date (August 5), they'll be included in 1.0. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
