Re: django bugfix releases
On di, 2010-05-25 at 17:22 -0700, Mikhail Korobov wrote: > I think the releases of stable micro-releases should happen more often > for 1.2. You guys are doing great job and it is not good to hide it > from developers. This issue has been raised before and improvements were promised. I believe that it will happen. -- Dennis K. They've gone to plaid! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django models should not contain 'evaluate' field/method since Django 1.1
On Tue, May 25, 2010 at 12:06 PM, naos wrote: > I was migrating some django project recently from django 1.0.4 to 1.2. > In Django 1.2/1.1 I found that if model have 'evaluate' attribute then > one will get exception in admin edit page for that model if the page > contains inline forms with related models: [snip] This is a bug and should be fixed by fixing the hasattr() check. Can you open a ticket, please? 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
django bugfix releases
I want to raise the question about stable django micro-releases. 1.1 - July 2009, 1.1.1 - October 2009 (released because of security bug), 1.1.2 - May 2010 So if some abstract developer want to use stable django release and follow all the instructions in docs he can get the half-year outdated django with a number of known bugs that are already fixed in svn. Please also consider what happen with the csrf_token template tag: it is in 1.1.2 to ease the migration to 1.2 but 1.1.2 is released alongside with 1.2 and not before 1.2. The most logical time for 1.2- preparing 1.1.2 release could be a feature freeze for 1.2 (months before the 1.2 release). I think the releases of stable micro-releases should happen more often for 1.2. You guys are doing great job and it is not good to hide it from developers. This is also can be solved with a bit of documentation. If the release process is time-consuming and is a waste of developers' time then there is an another way: add the suggestion to use stable svn branch somewhere in docs. This may be obvious for somebody that there is a stable django branch in the svn but I'm sure there are a lot of developers who don't know this. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: DjangoCon.eu is on right now
On May 25, 5:24 pm, Russell Keith-Magee wrote: > On Tue, May 25, 2010 at 2:41 PM, Graham Dumpleton > > > > > > wrote: > > > On May 24, 7:37 pm, Russell Keith-Magee > > wrote: > >> Hi all, > > >> This is a reminder to everyone that DjangoCon.eu is on during this > >> week. Jacob, Jannis, myself, and several other prominent django-dev > >> contributors are in Berlin, and as a result, we may not be able to pay > >> as much attention to django-dev as would would normally. > > >> So - if you post a Grand Proposal for Django 1.3 Awesomeness, please > >> don't be offended if we don't respond as quickly as we would normally. > > >> We will be sprinting at the conference on Thursday and Friday. If you > >> have a detailed proposal that would benefit from some round-table > >> discussion while several core developers are in the same room, please > >> post your proposal and we'll try to discuss it. Alternatively, if you > >> wait until early next week, life should return to relative normality. > > >> Yours, > >> Russ Magee %-) > > > Be nice if you can work out direction on uniform Django entry point > > for hosting such that behaviour is always the same and not different > > between development server and other hosting mechanisms. For why this > > is a problem with WSGI hosting see my blog post at: > > > http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html > > > If don't see it as an issue, then if you are at Sydney PyCon I can > > find you there and we can argue about it. :-) > > Yes, I'll be at Pycon.AU, so we should certainly use the opportunity > to thrash out some details if we can. I'll try and get some of the > discussion started during the sprints so I'll be well armed by the > time PyCon comes around. > > > BTW, I have separate ideas about making WSGI hosting simpler, but been > > hard so far to get anyone interested. Part of the problem is that > > authors of each hosting mechanism are content with their own way of > > doing things and don't appear to really want to cooperate in coming up > > with one better standard interface. :-( > > Armin Ronacher has been singing a similar song this week. I agree that > Django hasn't been good at interacting with the broader community when > it comes to this sort of issue. I could come up with all sorts of > excuses for why this is the case, but excuses won't fix anything -- > ultimately we just need to do better. >From what I understand of where Armin is coming from he wants to rewrite WSGI from scratch effectively based on everything we have learnt. I totally agree with that and have thought that for quite a while but saw it as a bit too hard to achieve. Momentum is changing though on this which is positive. What I am thinking of is not related to the WSGI interface itself but the mechanisms around creation and setup of the WSGI application for deployment. Not ready to explain it more at this point as don't really have the time and have preference for implementing a proof of concept as that would explain it better than any description. Graham -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: DjangoCon.eu is on right now
On May 25, 10:27 am, Jacob Kaplan-Moss wrote:
> At first glance, though, I'm thinking this looks pretty good -- though
> the log config file is giving me slight flashbacks to
> log4j.properties... /me shudders.
Do you mean this bit?
LOGGING = {
'version': 1,
'formatters': {
'default': {
'format': '%(asctime)s %(levelname)-1.1s [%(name)s] %
(message)s',
},
},
'handlers': {
'file': {
'class': 'logging.FileHandler',
'filename': '/tmp/logtest.log',
'mode': 'w',
'formatter': 'default',
},
'sqlfile': {
'class': 'logging.FileHandler',
'filename': '/tmp/logtest-sql.log',
'mode': 'w',
'formatter': 'default',
},
},
'root' : {
'level' : 'WARNING',
'handlers' : ['file'],
},
'loggers': {
'logtest': { 'level': 'INFO' },
'django': { 'handlers': ['file'] },
'django.core.urlresolvers': { 'level': 'DEBUG' },
'django.core.handlers.base': { 'level': 'DEBUG' },
'django.db.models.loading': { 'level': 'DEBUG' },
'django.db.backends.util': { 'level': 'DEBUG', 'propagate':
False,
'handlers': ['sqlfile'] },
},
}
That's using the PEP 391 schema which has been approved and
implemented in Python for 2.7/3.2. Obviously it's not the most minimal
configuration in this example - just something to illustrate multiple
log files (SQL and everything else) and the ability to set verbosity
of logging differently for different bits of Django. I'm not proposing
that this be the default for a Django settings.py file as created by
"django-admin.py startproject". A much simpler configuration is
possible, and no doubt we'll come up with one as the recipe gets
baked.
As far as the IRC thing goes - I'll try to be around Thursday and
Friday so that I can hook up with you on #django-sprint.
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Django models should not contain 'evaluate' field/method since Django 1.1
Hi, I was migrating some django project recently from django 1.0.4 to 1.2. In Django 1.2/1.1 I found that if model have 'evaluate' attribute then one will get exception in admin edit page for that model if the page contains inline forms with related models: Exception Value: 'Shipper' object has no attribute 'prepare' Exception Location: .../django/db/models/sql/expressions.py in __init__, line 12 It is caused by the fact that add_filter function in django/db/models/ sql/query.py does such a check: ... 1005. elif hasattr(value, 'evaluate'): 1006. # If value is a query expression, evaluate it 1007. value = SQLEvaluator(value, self) ... 1008. having_clause = value.contains_aggregate ... The problem is that "value" in this case is Shipper model which in have "evaluate" method so it is recognized as query expression here. I share about this cause I thought that maybe it is worth noting in documentation, or this check should be changed somehow? Greetings, -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: DjangoCon.eu is on right now
On Tue, May 25, 2010 at 10:28 AM, Vinay Sajip wrote: >> Agreed; Are you at the conference? If so, corner me at some point >> (either during the break or during the sprints); if you're not, I'll >> try and review the code at some point and give you some feedback. > > Sadly, I couldn't come to DjangoCon.eu. Have a great conference, and I > look forward to your feedback. If you can, try to jump onto #django-sprint at some point during the sprints and find me (jacobkm) or Russ (freakboy43234542334 or something) -- I'll be cornering Russ to talk about your proposal, so we might end up having some questions for you. At first glance, though, I'm thinking this looks pretty good -- though the log config file is giving me slight flashbacks to log4j.properties... /me shudders. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Progressing #8901 "last_insert_id() for postgres fails when the autoincrement sequence name is too long"
I think (from squinting at the code) that in Django 1.2 m2m field updates now use the object save code to add relationships even where there aren't specifically defined intermediate classes, whereas previously the code did its own insert in such cases. So as a consequence last_insert_id gets called as part of those m2m field updates in cases where it previously didn't. Because the table names for the m2m fields are generated from the class name and the field name together there is scope for them to be quite long and to hit the identifier limits and thus under postgresql the sequence name auto-generated for the id will not confirm to what the code currently guesses it to be (as per #8901) and so there'll be an error on updating m2m fields with 1.2 and postgresql in cases where there is a long enough field and class name and where it worked fine in 1.1. I've hit this myself on updating to 1.2. As #8901 hasn't been touched in a year (and has been sitting around since 2008) I thought I'd have a look at it myself. I've not submitted patches or tests for Django before, but I've had a stab at both for #8901. I'm not sure how to get this issue moved along closer to having a fix incorporated - it could certainly do with someone more expert than me in django and with postgresql knowledge reviewing my patch and tests (I've not flagged the issue has "has tests" as I skipped adding a test for one change for reasons I've noted on the issue, although maybe I should flag it thus). Regards, Matt -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: DjangoCon.eu is on right now
On May 25, 8:38 am, Russell Keith-Magee wrote: > > Your timing is dead on, and I'm personally interested in targeting > logging for 1.3. That's good news :-) > Agreed; Are you at the conference? If so, corner me at some point > (either during the break or during the sprints); if you're not, I'll > try and review the code at some point and give you some feedback. Sadly, I couldn't come to DjangoCon.eu. Have a great conference, and I look forward to your feedback. Regards, Vinay Sajip -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: DjangoCon.eu is on right now
On Tue, May 25, 2010 at 1:21 PM, Vinay Sajip wrote: > On May 24, 10:37 am, Russell Keith-Magee > wrote: >> >> We will be sprinting at the conference on Thursday and Friday. If you >> have a detailed proposal that would benefit from some round-table >> discussion while several core developers are in the same room, please >> post your proposal and we'll try to discuss it. Alternatively, if you >> wait until early next week, life should return to relative normality. > > Now that Django 1.2.1 has been released, I'd like to raise again the > question of introducing logging into Django, which was mooted by Simon > Willison (http://code.djangoproject.com/wiki/LoggingProposal) for > inclusion in 1.2, but then shelved for lack of time/other priorities. > I don't know if it's too early to bring this up for 1.3, but the > Python changes relating to dictionary-based configuration have been > added to Python (for inclusion in 2.7 and 3.2) and with a standalone > implementation (dictconfig) which can be co-opted for use in Django > with earlier versions of Python. Your timing is dead on, and I'm personally interested in targeting logging for 1.3. > The branch is at > > https://code.launchpad.net/~vinay-sajip/django/logging/ ... > This will allow anyone to review the changes made to Django to > I'd like to get some feedback on these changes, which are intended to > make it as easy as possible to introduce logging into Django itself as > well as configure logging with a Django site both for internal Django > operations as well as contrib apps and other, third-party Django apps. > > Since many of the core team will be at DjangoCon.eu, hopefully there > will be a chance while all are together to discuss the proposal about > logging. Agreed; Are you at the conference? If so, corner me at some point (either during the break or during the sprints); if you're not, I'll try and review the code at some point and give you some feedback. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: DjangoCon.eu is on right now
On Tue, May 25, 2010 at 2:41 PM, Graham Dumpleton wrote: > > > On May 24, 7:37 pm, Russell Keith-Magee > wrote: >> Hi all, >> >> This is a reminder to everyone that DjangoCon.eu is on during this >> week. Jacob, Jannis, myself, and several other prominent django-dev >> contributors are in Berlin, and as a result, we may not be able to pay >> as much attention to django-dev as would would normally. >> >> So - if you post a Grand Proposal for Django 1.3 Awesomeness, please >> don't be offended if we don't respond as quickly as we would normally. >> >> We will be sprinting at the conference on Thursday and Friday. If you >> have a detailed proposal that would benefit from some round-table >> discussion while several core developers are in the same room, please >> post your proposal and we'll try to discuss it. Alternatively, if you >> wait until early next week, life should return to relative normality. >> >> Yours, >> Russ Magee %-) > > > Be nice if you can work out direction on uniform Django entry point > for hosting such that behaviour is always the same and not different > between development server and other hosting mechanisms. For why this > is a problem with WSGI hosting see my blog post at: > > http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html > > If don't see it as an issue, then if you are at Sydney PyCon I can > find you there and we can argue about it. :-) Yes, I'll be at Pycon.AU, so we should certainly use the opportunity to thrash out some details if we can. I'll try and get some of the discussion started during the sprints so I'll be well armed by the time PyCon comes around. > BTW, I have separate ideas about making WSGI hosting simpler, but been > hard so far to get anyone interested. Part of the problem is that > authors of each hosting mechanism are content with their own way of > doing things and don't appear to really want to cooperate in coming up > with one better standard interface. :-( Armin Ronacher has been singing a similar song this week. I agree that Django hasn't been good at interacting with the broader community when it comes to this sort of issue. I could come up with all sorts of excuses for why this is the case, but excuses won't fix anything -- ultimately we just need to do better. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
