Re: New feature: Defining fieldsets in form class (Ticket #17301)

[Kiril Vladimirov]

+1

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/Xn1dFyUtjJsJ.
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.

Re: New feature: HTTP OPTIONS and improved HEAD for View

[Steven Cummings]

On Sun, Nov 27, 2011 at 4:17 PM, Jamie Matthews wrote:

> > 2. Improve the default HTTP HEAD handler by ensuring it has a blank body,
> > as this is the expectation of a response to a HEAD request. Also, there
> > should be consideration for the GET handler not existing, which should
> > result in a 405. The code appears to assume it exists, which would result
> > in an AttributeError instead.
>
> For previous discussion on this, see this ticket:
> https://code.djangoproject.com/ticket/15668
>
> * Graham Dumpleton disagrees with your first point: "Python web
> applications should never themselves discard the response content for
> HEAD requests. They should always return the request content and allow
> the underlying WSGI server or hosting web server to discard the
> request content."
>

Interesting. I hadn't taken the wsgi implementation into account. This
seems to preclude app-servers from implementing HEAD with any shortcuts
(e.g., cache the headers). Anyway, we'll leave this alone then...


>
> * My original implementation of the "head" method on the View base
> class [1] *did* check whether the view already has a "get" method.
> This was later changed in [2] to the current semantics which, I agree,
> looks a bit wrong. Perhaps we should revert to the original behaviour?
>
> [1] https://github.com/django/django/commit/c7fe43
> [2] https://github.com/django/django/commit/760d0f


Yeah, that implementation seems preferable. What was the reason for backing
it 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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: New feature: HTTP OPTIONS and improved HEAD for View

[Jamie Matthews]

> 2. Improve the default HTTP HEAD handler by ensuring it has a blank body,
> as this is the expectation of a response to a HEAD request. Also, there
> should be consideration for the GET handler not existing, which should
> result in a 405. The code appears to assume it exists, which would result
> in an AttributeError instead.

For previous discussion on this, see this ticket:
https://code.djangoproject.com/ticket/15668

* Graham Dumpleton disagrees with your first point: "Python web
applications should never themselves discard the response content for
HEAD requests. They should always return the request content and allow
the underlying WSGI server or hosting web server to discard the
request content."

* My original implementation of the "head" method on the View base
class [1] *did* check whether the view already has a "get" method.
This was later changed in [2] to the current semantics which, I agree,
looks a bit wrong. Perhaps we should revert to the original behaviour?

[1] https://github.com/django/django/commit/c7fe43
[2] https://github.com/django/django/commit/760d0f

-- 
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.

Re: I've made good progress in porting Django to Python 3, and could use some help!

[Vinay Sajip]

On Nov 27, 2:10 pm, Kiril Vladimirov  wrote:
> Have you made some sort of TODO list I could use?
> Or selecting some failing test and make it run fine would be fine as well?

I would say: just clone the repo, try to reproduce the results, report
any differences you find from my results, and select any failing test
to fix.

Another area to look at is to exercise other database backends, e.g.
PostgreSQL. I've only looked at sqlite as the obvious backend to use
first.

> Also, how about moving this project to GitHub?
> Django is there, too(https://github.com/django/) and I thing we could find
> more participants.

It just so happened that I found the BitBucket mirror first and used
that, but I wouldn't expect a serious developer, who wants to pitch
in, to object to using Mercurial and BitBucket instead. There's very
little to choose between them (BitBucket/GitHub), compared to the real
work still to be done in getting Django production-ready on 3.x.

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-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.

Re: Django application instances

[Chris Northwood]

Hi all,

I've been playing around this the branch on github for a while now,
but unfortunately me knowledge of Django's internals only goes so far
with regards to getting multiple instance support working fully,
particularly around how models work. I've got to the point where you
can now instantiate multiple copies of apps with distinct labels, and
these are registered in the cache:
https://github.com/cnorthwood/django/commit/52016c83b8794616b57c2296d23fb56e29a451a9

At present, this only registers one set of models and doesn't consider
the custom app_label

There are a few unanswered questions too:

* how would directly accessing a model work in a multi-instance
scenario? i.e., MyModel.objects.all() vs. get_model('my_app_instance',
'MyModel').objects.all()
* how would a view know which instance of an app it's supposed to be
responding to? One way may be to have the routing add an attribute to
the request object giving information about which app this set of URLs
belong to, i.e., put include(get_app('my_instance').urls) or similar
in the urlconf, and then when the view is called, it could perhaps
access the app object using request.app, or similar?

Thoughts?

Chris

-- 
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.

Re: New feature: Defining fieldsets in form class (Ticket #17301)

[Daniel Swarbrick]

+1

I've often wondered why fieldsets have been possible in the Django
admin interface for a while now, but not possible with ModelForms.
Looking forward to this.

On Nov 27, 12:43 am, Mikołaj Siedlarek  wrote:
> Hi,
>
> I've just posted a new ticket with everything the feature proposal needs -
> motivation, idea and actual implementation.
>
> https://code.djangoproject.com/ticket/17301
>
> It definitely needs some discussion, so please -- ask, discuss, criticize,
> share some thoughts and one day, hopefully +1. :)
>
> 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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: I've made good progress in porting Django to Python 3, and could use some help!

[Kiril Vladimirov]

Have you made some sort of TODO list I could use? 
Or selecting some failing test and make it run fine would be fine as well?

Also, how about moving this project to GitHub? 
Django is there, too(https://github.com/django/) and I thing we could find 
more participants.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/wTlyOMg5dYkJ.
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.