APPEND_SLASH only 500's for POST, not for PUT/DELETE. Intentional?
Ran into this recently and it seemed counterintuitive. The APPEND_SLASH functionality 500's for POST, but returns a 302 for PUT (and I assume DELETE after looking at the source). Is that intentional? It surprised me that POST/PUT/DELETE wouldn't all share behavior in this case. Thanks in advance, Phill -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/969774ab-bf70-4e2a-908d-9f043ca77da3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Auto-import support for models and other objects in shell
Totally fair, couple of things: 1. For backward compatibility and the confusion you mentioned, I'd suggest this be not enabled by default. Let people who want the feature (the people who download shell_plus for instance) enable it. My pull request leaves it totally off by default, retaining current behavior. In my opinion this removes the 'magically available' argument. The classes would be as magically available as context vars in templates are. 2. Are you also -1 on making it easier for projects like shell_plus to add locals to the shell? What's happening right now is pretty unfortunate. I can only see upside in an adjustment to the internal API that doesn't make this kind of duplication necessary. Thanks for reading. Phill On Tuesday, August 28, 2012 2:42:43 PM UTC-7, Alex_Gaynor wrote: > > > > On Tue, Aug 28, 2012 at 2:40 PM, Phill Tornroth > <famous...@gmail.com > > wrote: > >> 'Ello. >> >> I'm gauging support for a tiny new feature, or at least a refactoring of >> an internal API that will allow the feature to be developed without code >> duplication. I'd like to stop typing import statements for all of my models >> and other common stuff into my django shell. In fact, I'd love for all of >> us to stop typing those import statements! I tossed up the following pull >> requests as an example for how this might look: >> >> https://github.com/django/django/pull/303 >> >> This is effectively a subset of the functionality that shell_plus [1] >> appears to provide. The problem that I have with building my own, or with >> using shell_plus is that the shell command doesn't allow this change to be >> built without effectively copying the entire internal implementation of the >> shell command. New features added to, or issues fixed in shell will have to >> be copied over to shell_plus, or our homegrown solutions which is >> unfortunate. So at the very least it seems reasonable to provide something >> like the get_initial_shell_locals method I added in my pull request, >> which makes this feature easy enough to add without duplication. >> >> In fact, that's where my thinking started but I also don't see a downside >> to providing this functionality in core either. I don't think it's >> usefulness is particularly questionable or niche, as the existence of >> shell_plus seems evidence of. >> >> I haven't opened a ticket because the contribution docs suggest gauging >> consensus, first. So I think these are the two potential (not mutually >> exclusive) changes worth gauging support for: >> >> 1. An overridable method (or some other internal API change?) to make it >> possible to implement this functionality without copying the entire shell >> implementation. >> 2. A default implementation for said method that supports auto-importing >> useful objects into the shell scope. >> >> >> Curious to hear what people think. Of course, please let me know if I'm >> going about this the wrong way. >> >> Thanks! >> Phill >> >> [1]: >> https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/shell_plus.py >> >> -- >> 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/-/gcpo73Sk5aMJ. >> To post to this group, send email to >> django-d...@googlegroups.com >> . >> To unsubscribe from this group, send email to >> django-develop...@googlegroups.com . >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> > > I'm pretty strongly -1 on this. I understand it can be a real convenience, > but this is precisely the type of feature that makes things way more > confusing for anyone who's new to a project, "Why are the things magically > available here?". I realize this is "just" the shell, but I've been very > critical of other frameworks for making things magically available, and I'm > going to hold us to the same standard. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing 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 view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/a4TV7rbfzsMJ. 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.
Auto-import support for models and other objects in shell
'Ello. I'm gauging support for a tiny new feature, or at least a refactoring of an internal API that will allow the feature to be developed without code duplication. I'd like to stop typing import statements for all of my models and other common stuff into my django shell. In fact, I'd love for all of us to stop typing those import statements! I tossed up the following pull requests as an example for how this might look: https://github.com/django/django/pull/303 This is effectively a subset of the functionality that shell_plus [1] appears to provide. The problem that I have with building my own, or with using shell_plus is that the shell command doesn't allow this change to be built without effectively copying the entire internal implementation of the shell command. New features added to, or issues fixed in shell will have to be copied over to shell_plus, or our homegrown solutions which is unfortunate. So at the very least it seems reasonable to provide something like the get_initial_shell_locals method I added in my pull request, which makes this feature easy enough to add without duplication. In fact, that's where my thinking started but I also don't see a downside to providing this functionality in core either. I don't think it's usefulness is particularly questionable or niche, as the existence of shell_plus seems evidence of. I haven't opened a ticket because the contribution docs suggest gauging consensus, first. So I think these are the two potential (not mutually exclusive) changes worth gauging support for: 1. An overridable method (or some other internal API change?) to make it possible to implement this functionality without copying the entire shell implementation. 2. A default implementation for said method that supports auto-importing useful objects into the shell scope. Curious to hear what people think. Of course, please let me know if I'm going about this the wrong way. Thanks! Phill [1]: https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/shell_plus.py -- 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/-/gcpo73Sk5aMJ. 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: Ticket 10790 - Things got much worse in Django 1.4
Anssi, Thanks. The comments were helpful and I've looked at the patch enough (again, I'm not it's author) that I think I can clean up the comments, break out the tests, and do a better job communicating exactly what it's up to with around a day's worth of effort. I'm gonna try to fit that into my schedule early next week... that is, unless someone else better prepared than me speaks up and wants to get involved. Everything else you said is terrifying. Phill On Thursday, August 2, 2012 2:00:58 PM UTC-7, Anssi Kääriäinen wrote: > > On 2 elo, 19:17, Phill Tornroth <famousactr...@gmail.com> wrote: > > I just submitted a comment about some testing I did that led to > discovering > > that in 1.4.x, certain queries with null checks in them produce much > less > > efficient SQL than they did in prior versions. > > > > A patch that was originally submitted a couple years ago and revised > > recently by it's author fixes the original problem (submitted against > 1.1) > > and the new badness that came along with 1.4.x: > > > > https://code.djangoproject.com/ticket/10790 > > > > That said, the ticket is really old, so I wanted to see if there are > some > > non-obvious reasons for resisting moving forward with a merge, and > discuss > > the possibility of this landing in a 1.4 release as opposed to only on > > master. The regression that 1.4.x introduced makes it near impossible > for > > me to move my project past 1.3.x at the moment, and as I mentioned in > the > > ticket... this patch ought to speed up lots of queries for basically > anyone > > with a serious project. > > > > So... what can I do to help? > > I have added some comments to the ticket. > > Not related to this ticket in particular: the more general problem > with ORM fixes is that there seems to be nobody around who understand > the ORM completely. The code is complex, and it is hard to see what > happens, and especially why things are done in the way they are done. > This is the reason why many ORM tickets are stalled - it is really, > really hard to see if a patch is correct, as understanding the whole > logic in the ORM is so hard. > > - Anssi > -- 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/-/A9BKpMHGzJgJ. 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.
Ticket 10790 - Things got much worse in Django 1.4
I just submitted a comment about some testing I did that led to discovering that in 1.4.x, certain queries with null checks in them produce much less efficient SQL than they did in prior versions. A patch that was originally submitted a couple years ago and revised recently by it's author fixes the original problem (submitted against 1.1) and the new badness that came along with 1.4.x: https://code.djangoproject.com/ticket/10790 That said, the ticket is really old, so I wanted to see if there are some non-obvious reasons for resisting moving forward with a merge, and discuss the possibility of this landing in a 1.4 release as opposed to only on master. The regression that 1.4.x introduced makes it near impossible for me to move my project past 1.3.x at the moment, and as I mentioned in the ticket... this patch ought to speed up lots of queries for basically anyone with a serious project. So... what can I do to help? Thanks in advance, Phill -- 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/-/JOTWVb3Slk4J. 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.
