I would agree with you on the dict issue, given that some of the backends have custom settings etc. I also agree that this is not really something that matters now - DSNs will need to be parsed into dicts anyway, so you might as well implement the dicts first and then see what the demand is for DSNs. Supporting both also doesnt seem too bad.
Mile. On Friday, May 1, 2009, Alex Gaynor <alex.gay...@gmail.com> wrote: > Hi all, > > Not a lot of new news or progress. I'll be at EuroDjangoCon all of next week > so I may be starting my work there, depending on the status of 1.1. The only > new news was Simon and I discussed switching to a DSN string in place of the > dict of settings. Personally I'm -1 on that as I find the current setup very > readable and doesn't require us to parse strings. However, more importantly, > I think it's fairly orthagonal to multidb, and as such should be handled > seperately. I think Simon will be at EuroDjangoCon so hopefully I'll have a > chance to dicuss it with him there. > > As always, questions, criticisms, curse laden rants, and really good ideas > are welcome, > Alex > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." --Voltaire > "The people's good is the highest law."--Cicero > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
