Re: Deprecating logout via GET

On 2020-03-02 18:35, Anna Sidwell wrote: > Is there any particular reason why it shouldn't look like a button > instead of a link? The concern isn't how it looks (with CSS you can make a button look like a link, or make a link look like a button). An does the logout action via a GET (and is the

Re: Are there use cases for storing null bytes in CharField/TextField?

On 2017-05-15 08:54, Tim Graham wrote: > Does anyone know of a use case for using null bytes in > CharField/TextField? Is this not what BinaryField is for? It would seem to me that attempting to store binary NULL bytes in a CharField/TextField should result in an error condition. -tkc --

Re: Proposal: add new template tag "age"

On 2015-11-11 14:44, Collin Anderson wrote: > Also, doing this from the backend seems like sub-par way to do it. > I would recommend implementing this in javascript, so it can > auto-update over time if you leave the window open. It shouldn't be limited to one or the other: doing it on the

Re: Making max_length argument optional

On 2015-09-22 07:49, Aymeric Augustin wrote: > > And for your concern, there will be a MaxLengthValidator added to > > the validators to validate the users input does not exceed the > > database backends maximum length just like when you set > > max_length explicitly. > > This isn’t possible in a

Re: A general way to batch SQL queries in Django

On 2015-02-27 06:12, Josh Smeaton wrote: > The concept of batched SELECT statements doesn't really exist in > SQL, unless the relations you're selecting have identical column > types. Example: > > SELECT name, age_in_years FROM person > UNION ALL > SELECT item_name, quantity FROM item; > > The

Re: resurrecting an old friend, whitespace in forms, #6362

[slightly reordered] On 2015-02-04 18:25, Collin Anderson wrote: > Also, did we decide if the Model-field-layer or Form-field-layer > would be better? I think the Form-field layer is definitely the place for it. If I do my_model.my_text_field = " leading and trailing " I expect that value to

Re: CSRF REASON_NO_REFERER with meta referrer tags

On 2015-02-03 10:31, Aymeric Augustin wrote: > Your request boils down to "make Django's CSRF protection of HTTPS > pages vulnerable to MITM attacks" which isn't acceptable. If you've got a MITM that can intercept HTTPS, is there any reason to assume they aren't in a position to spoof DNS as

Status of #15619: logout via POST, but not GET

I've had a couple cases where browser link pre-fetching triggered an unintended logout from my Django app (I haven't fully tracked down the exact combination of triggering conditions, but I suspect they similar to Israel Brewster's CherryPy issue mentioned on comp.lang.python [1]) and was

Re: What are the best reasons for when and why people should use Django?

On 2014-08-10 01:06, Josh Johnson wrote: > Django documentation is phenomenal, I second Josh's comment. I'd naively assumed that all "big Python web-framework" documentation was as good as Django's. However, when I had to do some work on a contract involving CherryPy and SQLObject...marcy was

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

n 2014-01-20 20:22, Aymeric Augustin wrote: > The alternative is to modify INSTALLED_APPS to support passing > arguments to the AppConfig class. But I find it rather ugly. [I've only been lurking in this thread, so take with a grain of salt; just throwing it out there to see what sticks] Would

Re: #18659 -- Deprecating request.REQUEST

On 2013-10-16 11:10, Javier Guerra Giraldez wrote: > On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger > wrote: > > However, it does so by blurring the distinction between GET and > > POST parameters, which like other people here, I find > > disturbing. > > care to elaborate about

Re: Allowing custom attributes in Meta classes

On 2013-09-10 21:05, Russell Keith-Magee wrote: > So - I think custom Meta options are something that should be > *possible*. I don't have any particular ideas for how it should be > implemented, though. One of the areas I've considered trying this is annotating "private" information about

Re: Security Advisory: BREACH and Django

On 2013-08-08 09:59, Collin Anderson wrote: >> I am doing something a little different with my CSRF tokens, and >> I believe it guards against BREACH. > > Instead of sending the token in the HTTP response, I am using > javascript to read (and generate if needed) the CSRF token cookie. > The

Re: Security Advisory: BREACH and Django

On 2013-08-06 12:53, Donald Stufft wrote: > On Aug 6, 2013, at 12:16 PM, Tom Scrace wrote: >> On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss >> wrote: >> >> We plan to take steps to address BREACH in Django itself, but in >> the meantime we recommend that all

Re: reconsider re-opening ticket 901

On 2013-05-14 10:43, Alex Ogier wrote: > What happens in the following case? > > a = A(dict_field={"hello": "world"}) > d = a.dict_field > a.save() > a.refresh() > d["hello"] = "planet"# does this mutate a.dict_field? does the > answer change if somebody changed the database in between saving

Re: reconsider re-opening ticket 901

On 2013-05-11 18:36, Anssi Kääriäinen wrote: > On 12 touko, 02:55, Russell Keith-Magee > > What is on the table is essentially adding a refresh() call on an > > object instance that is an API analog of > > ".get(id=self.id)" I guess my minor quibble is about the name

Re: Using EXISTS instead of IN for subqueries

On 2013-03-26 15:54, Michael Manfre wrote: > On Tue, Mar 26, 2013 at 12:40 PM, Anssi Kääriäinen > deal with limit/offset. A generic approach would be nice to have, > but I can't imagine a generic way that would let me generate the > "SELECT ... FROM (SELECT ROW_NUMBER() OVER (...)) WHERE ..." >

Re: Using EXISTS instead of IN for subqueries

On 2013-03-25 22:16, Michael Manfre wrote: > On Monday, March 25, 2013 6:58:12 AM UTC-4, Tim Chase wrote: > > I can only speak for testing IN-vs-EXISTS speed on MSSQLServer at > > $OLD_JOB, but there it's usually about the same, occasionally > > with IN winning out

Re: Using EXISTS instead of IN for subqueries

On 2013-03-25 03:40, Anssi Kääriäinen wrote: > I am very likely going to change the ORM to use EXISTS subqueries > instead of IN subqueries. I know this is a good idea on PostgreSQL > but I don't have enough experience of other databases to know if > this is a good idea or not. I can only speak

Note of thanks to the release-managers

I just read through the novel that is docs/internals/howto-release-django.txt and I have a new level of respect for just what happens when a release is made. That's a LOT of work. So thanks to those that wade through the whole process! -tkc -- You received this message because you are

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

On 08/26/10 13:25, Jeff Balogh wrote: In our case the pref was accidentally disabled when testing add-ons, but people do intentionally turn off Referer for privacy reasons. I don't know if requiring Referer under https is a good idea. RFC-2616 makes it pretty clear that one should never

Re: Invalid SQL generated by objects.all()[:1]?

On 07/15/2010 01:28 PM, Mark Bucciarelli wrote: not sure why a subselect would ever need an order by anyway. i'll have to figure out exactly what django operation generated that sql. The only time I've needed an ORDER BY in a subselect involved a LIMIT/TOP in the subselect SELECT ...

Re: Proposal: Revised form rendering

Your proposal really needs to cater to two different audiences: 1. People who will use the new {% form myform %} where they just want all the fields rendered without any fuss, much like {{ form }} now. 2. The tweakers that need to control every aspect of the each field being rendered. I'd say

Re: Proposal: Revised form rendering

On 07/12/2010 07:03 AM, Russell Keith-Magee wrote: On Mon, Jul 12, 2010 at 5:43 AM, Tim Chase <django.us...@tim.thechases.com> wrote: [please excuse the slight chop-up-and-reordering of your original into my quoting] Only if you grant me the same liberty :-) Fair's onl

Re: Proposal: Revised form rendering

On 07/12/2010 08:12 AM, Russell Keith-Magee wrote: On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson wrote: Good proposal overall. One thought I have in order to try and combat the massive parameter list of {% form %} is to optionally add an ending tag, as well as sub-tags:

Re: Proposal: Revised form rendering

[please excuse the slight chop-up-and-reordering of your original into my quoting] On 07/11/2010 10:36 AM, Russell Keith-Magee wrote: {% form myform %} For what my vote may be worth, I'm -0 on this... {% form myform field birthdate using calendar %} and -1 on this {% form myform field

Re: a default max_length

> How do you feel about having a default max_length value for a > models.CharField, so we can use it like: > class MyModel(models.Model): > example = models.CharField() > > What are the pros and cons? I'm pretty -1 against it. Pros: + you get to be lazy in one particular use-case, for

Doc building piece missing?

Just noticed this in [1] -- csrf_tokenś New in Django 1.1.2: System Message: WARNING/2 (/home/djangodocs/en/dev/ref/templates/builtins.txt) undefined label: releases-1.1.2 -- Looks like some tag/label needs to be

Re: ORM roadmap

> I find an orm usefull for 3 scenarios: > 1. - simple object retrieval posts.objects.all() > 2. - performance optimized object retrieval, your raw approach would > suffice here > 3. - generating complex queries, and reusing sql components > When you get to complex data models, Django currently

Re: Proposal for 1.2: Dumber email validation

> 1) If we encourage people to write their own regex if they want > tighter email validation, we run the risk that users will > inadvertently introduce the same bug that we have just fixed. Russell raises my biggest concern with this proposal. There are a lot of smart folks in the

Re: Check Constraints for databases that support them

> Is there anyone else interested in this? yes, I'd be interested in seeing some sort of database-level CHECK constraint as part of Django. I had been sitting on my thoughts until I see the GSoC work done on model-validation wend its way towards trunk. My hope had been to see model

Re: USStateField (again)

James Bennett wrote: > The current proposal is for a "USPostalCodeField" which > corresponds to the US Postal Service's list of postal codes: > > http://www.usps.com/ncsc/lookups/abbr_state.txt > > [snip] Based on the various arguments up to this point, it > seems like no single field is going

Re: #10355 Add support for email backends

> In terms of the SMTP-specific settings (host, port, username, password > and use_tls), I personally feel that those parameters should be in the > settings module and not in the code. Although at the moment, > django.core.mail will use certain settings if said parameters are left > out.

Re: [GSoC] model validation - update

Honza, Thanks for all your work on this -- model-validation is something I missed when it was removed (well, moved to forms), so you have one of my favorite GSoC projects. > Questions for the community: > - > I have been toying with the idea of abstract validating

Re: Posting to the wrong list (was: Re: Need Django Developer urgent)

> How about: > > "You're found the wrong list. You're probably looking for django-users > unless you're interested in the development of the Django framework itself." +1 [waves hand] This is not the list you are looking for. -tim --~--~-~--~~~---~--~~ You

Re: [GSOC] Multiple Database API proposal

> I'm here soliciting feedback on both the API, and any potential hurdles I > may have missed. While my vote may mean little, Alex has certainly been active and had quality code on the mailing list. MultiDB has also been a frequent issue on the mailing-list, so Alex gets my +1 I'd hope to

Re: proposal: forloop previous and next

Santiago Perez wrote: > Hi, I found myself needing to reference the previous or next > element of a list within a for loop of a template. I think it > would be pretty easy to implement the following extra members > to the forloop context variable: > > + forloop.next_element > +

Re: Joins and aggregates

>> 1) Prevent joins at the query level. Keep track of the joins >> that are being used for aggregates, and only allow one join. >> This would mean killing a lot of queries that work correctly >> right now, but would prevent the class of invalid queries. >> >> 2) Push aggregates into subqueries.

Re: Dropping Python 2.3 compatibility for Django 1.1

James Bennett wrote: > Apologies for the length of this email, Thanks, James, for your post-doctoral dissertation on the History and Cumulative Predicted Future of Python Versions and Their Interrelations With the Django Development Process. :-) (joking aside, it was an appreciated and

Re: Dropping Python 2.3 compatibility for Django 1.1

> I'd like to officially drop Python 2.3 support in Django 1.1. > Discuss. +0.5 (not withstanding any panic'ed folks saying "I need 2.3!", consider it a +1) I think Debian Stable has moved to 2.4. All the servers that I touch currently with 2.3 on them now also have 2.4 on them. Yay,

Re: "New in development version" equivalent in current docs?

> I'm still coming to grips with Sphinx, but is there any reason that we > can't just use 1.X or 1.SVN as a version number for the development > version? That gets around the need to specify the exact version > number, but keeps it reasonably obvious that it's a development > version. If

Re: Django releases

> I'd trade your controversial part for an alternative: merge mewforms-admin > back to trunk now. It's been as 'usable' as old admin for months. Sure, > it's got a couple of dozen 'blocking' bugs in the tracker but none of them > are all that serious. Current admin, as you note, also has some

Re: Django releases

>> * Start a "train release" schedule: schedule a couple of 1.0 betas, a >> rc or two, and then a final release. Features that are done by the >> dates get released, those that aren't, don't. Make these dates >> aggressive but not crazy. And -- here's the controversial part -- make >>

Re: Aggregation Updates

> To my understanding, a slice isn't automatically a copy - it will be > in most cases, but there are cases where the bytecode compiler will > use the original list as an optimization. One example: > > >>> s = 'abc' > >>> t = s[:] > >>> s is t > True > > I'm willing to be corrected here, but

Re: Aggregation Updates

> * On a similar note, I can see a lot of places where you > seem to be copies of lists (or sublists) - this is an > expensive operation if you do it a lot, especially since > most cases you could get the same effect by keeping the > index values and slicing the original list as required. >

Re: Newbe questions (firebird)

>> The real problem is when I try to access the database. I get >> stack trace below. It looks like it is trying to use the >> LIMIT keyword incorrectly. As best I can tell, Firebird doesn't support the SELECT ... LIMIT x OFFSET y" notation, but rather uses "SELECT FIRST x [SKIP y] ..." as

Re: _QuerySet.first()

> I poked around 'django.db.model.query' this morning and noticed that > '_QuerySet' class has 'latest(self, field_name=None)' method. I was > wondering if adding 'first(self, field_name=None)' had been considered > before. > > It seems that could be a useful shortcut in some instances. Does

Re: Maybe DEBUG=True should only record the last N SQL queries?

> If we want to crash and burn if you use DEBUG=True in > production we should do that explicitly, not as a side effect > of another feature. I think there is enough real-world > evidence that people are being tripped up by this for > legitimate reasons (running import scripts in development >

Re: Model Inheritance

>> class X(models.Model): >> x = models.CharField() >> >> class Y(X): >> y = models.CharField() >> >> class Z(X): >> z = models.CharField() >> >> produced the tables >> >> x(id, x) >> y(id, x, y) >> z(id, x, y, z) >> >> All I need to know is if this is some kind of fall-back till full- >>