exception handling memory leak...
http://code.djangoproject.com/ticket/10758 Can we fix this? It's a pretty easy fix. thanks, -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-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.
[GSOC] Query-Refactor
Hey all, As you're likely aware this summer I'll be a GSOC student responsible for query-refactor (aka "NoSQL") in Django. Basically the next couple of weeks are going to involve me ripping up a bunch of internals, and in the interest of keeping the SVN branch stable I'll be committing that work to a branch on Github, and only merging back once we have test passage. Thanks, 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 "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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: Proposal: Replace django.contrib.formtools.wizard
On Sat, May 29, 2010 at 22:07, Stephan Jäkel wrote: > I already discussed this ticket with Jannis during the sprints and hope to > start a discussion here to find the right way to allow file uploads and see > if my approach takes the right direction. > Couldn't you just use python's *tempfile.NamedTemporaryFile*[1]? That way the file will get cleaned by the filesystem itself, unless you move it somewhere else in your ``done`` method. If you pass delete=False, you will be able to open the file again in the last step, as long as you properly closed it before. TiNo [1] http://docs.python.org/library/tempfile.html#tempfile.NamedTemporaryFile -- 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: Proposal: Replace django.contrib.formtools.wizard
On Sun, May 30, 2010 at 12:33 PM, Harro wrote: > We had a site where we needed a wizard with the ability to go back and > forward and store files. > Only allowing files in the last step really isn't an option imho, that > just avoiding the problem ;-) > > What we did was simply store the files in a temporary folder and have > a management command to clean them up when needed. (The files where > stores with a timestamp in the name so we knew when they where old). > > I'm for having a better form wizard in django. +1 > > > > On May 30, 11:15 am, Jacob Kaplan-Moss wrote: >> Hey Steph -- >> >> I've had a chance to play with your code, and I'm impressed and >> generally +1 on replacing formwizard with yours. >> >> I couldn't tell from my quick play, though, if there were any >> backwards-incompatible changes. There's a fair bit of code churn (in a >> good way :), so before we could merge this I'd like a sense of what >> any backwards-compatibily concerns would be. >> >> Thanks! >> >> 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. > > My one comment (and we discussed this on IRC) is that this really should inherit from GenericView IMO, so it'd be nice if that landed before this. 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 "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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: More flexible choices validation in models.Field
On 29.05.2010 19:23, Jannon Frank wrote: This produces a validation error on MyModel because it is checking the combined string (e.g. '1,2,5') against the list of choices, when the intent is to have each of the values in the string checked individually against the choices. Is there any disagreement at all? To me, this looks simply like a bug, so can you file a ticket for it, please? Tickets don't get lost as easily as tickets. Kind regards Michael -- 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: Proposal: Replace django.contrib.formtools.wizard
We had a site where we needed a wizard with the ability to go back and forward and store files. Only allowing files in the last step really isn't an option imho, that just avoiding the problem ;-) What we did was simply store the files in a temporary folder and have a management command to clean them up when needed. (The files where stores with a timestamp in the name so we knew when they where old). I'm for having a better form wizard in django. +1 On May 30, 11:15 am, Jacob Kaplan-Moss wrote: > Hey Steph -- > > I've had a chance to play with your code, and I'm impressed and > generally +1 on replacing formwizard with yours. > > I couldn't tell from my quick play, though, if there were any > backwards-incompatible changes. There's a fair bit of code churn (in a > good way :), so before we could merge this I'd like a sense of what > any backwards-compatibily concerns would be. > > Thanks! > > 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.
Re: Proposal: Replace django.contrib.formtools.wizard
Hey Steph -- I've had a chance to play with your code, and I'm impressed and generally +1 on replacing formwizard with yours. I couldn't tell from my quick play, though, if there were any backwards-incompatible changes. There's a fair bit of code churn (in a good way :), so before we could merge this I'd like a sense of what any backwards-compatibily concerns would be. Thanks! 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.
Re: Class based generic views in 1.3?
Maybe I missed something, but why don't you use __new__ instead of
copying the instance?
Bye,
Waldemar
On May 29, 11:06 pm, Ben Firshman wrote:
> Luke, you're absolutely right that changing the definition of a view is a bad
> idea, it just seemed the best solution then.
>
> But don't worry, we've changed our minds again! If __call__() creates a copy
> of self and calls methods on the copy, as far as I can see it solves all our
> problems. No boilerplate, and it's really hard to make it unsafe thread-wise.
>
> An example of how it could work:
>
> http://github.com/bfirsh/django-class-based-views/blob/master/class_b...
>
> Thanks
>
> Ben
>
> On 29 May 2010, at 00:07, Luke Plant wrote:
>
>
>
> > On Friday 28 May 2010 15:51:32 Jacob Kaplan-Moss wrote:
>
> >> My only real objection here is that `as_view` is just a bunch of
> >> boilerplate::
>
> >> urlpatterns = patterns('',
> >> ('one/', SomeView.as_view()),
> >> ('two/', SomeOtherView.as_view()),
> >> ('three', YourView.as_view())
> >> )
>
> >> I just really don't like the way that looks.
>
> > Agreed. I also think that if you have a mixture of normal views and
> > class based view, this is ugly:
>
> > urlpatterns = patterns('app.views',
> > ('one/', 'some_view_function',
> > ('two/', SomeOtherView),
> > ('three/', YourView)
> > )
>
> > and it would be nicer to spell it:
>
> > urlpatterns = patterns('app.views',
> > ('one/', 'some_view_function'),
> > ('two/', 'some_other_view'),
> > ('three/', 'your_view')
> > )
>
> > and have these additional lines in 'app.views':
>
> > some_other_view = SomeOtherView.as_view()
> > your_view = YourView.as_view()
>
> > I know that is just moving the boilerplate around, but it is giving a
> > consistent interface. If some code in a re-usable app moves from
> > normal views to class based views, they will have to do something like
> > this *anyway* for backwards compatibility.
>
> > But I can see that if subclassing is the default way of re-using, then
> > exporting these functions gives multiple options about how they should
> > be re-used, which you are wanting to avoid.
>
> >>> There is also the issue of what to do when you need to add a
> >>> decorator to someone else's view function.
>
> >> Again, I want to encourge "subclass it" as the correct answer here.
>
> > In that case, I guess it would be good to make this hard to do wrong,
> > by providing helpers that add the decorator to the right end of the
> > list of decorators.
>
> > Regards,
>
> > Luke
>
> > --
> > "Oh, look. I appear to be lying at the bottom of a very deep, dark
> > hole. That seems a familiar concept. What does it remind me of? Ah,
> > I remember. Life." (Marvin the paranoid android)
>
> > Luke Plant ||http://lukeplant.me.uk/
>
> > --
> > 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
> > athttp://groups.google.com/group/django-developers?hl=en.
--
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: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py
-1. The only issue that I have with sites is that the default site should be 127.0.0.1:8000 since that's what runserver defaults to. Putting example.com as SITE_ID 1 only makes novice django developers shout and throw things because like me they 'add 127.0.0.1:8000 and delete example.com' instead of replacing example.com and wonder why runserver isn't serving their first hello world flatpage. I had a blog post which included this tip, and it amazes me how many people commented they had done the same thing, which suggests there is a large number of people who make this simple but avoidable mistake. Since nobody will ever use 'example.com' it should not be there in the first place. On May 24, 12:16 pm, Rolando Espinoza La Fuente wrote: > On Tue, May 18, 2010 at 11:14 AM, Felipe Prenholato > > wrote: > > About idea of use settings.py to set a default site, -1 > > About ask to user what is yours default site, +1 > > This thing only runs at syncdb, so I really don't think that a entry in > > settings.py is needed. > > This seems a controversial topic :) > > +1 to the idea to just ask in syncdb, in the same way that admin user > is created. > Here is my proposal:http://gist.github.com/411456 > > Regards, > > ~Rolando > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
