Re: Self-referenced template recursion handling

On Monday, December 9, 2013 12:43:04 PM UTC+1, Goinnn wrote: > > 1. Efficiency: If this new solution slows the compilation/find/render > template, I dislike it > Lots of "ifs" which are not really worth discussing before we run actual benchmarks; also I think that it won't be slower since curren

Re: Self-referenced template recursion handling

On Monday, December 9, 2013 5:18:16 PM UTC+1, Goinnn wrote: > > 2013/12/9 Florian Apolloner > > >> On Monday, December 9, 2013 12:43:04 PM UTC+1, Goinnn wrote: >>> >>> 1. Efficiency: If this new solution slows the compilation/find/render >>> templat

Re: Self-referenced template recursion handling

pelli templates just to get self referencing templates wouldn't be nice, I think we can agree on that? On Monday, December 9, 2013 7:09:48 PM UTC+1, Florian Apolloner wrote: > > > > On Monday, December 9, 2013 5:18:16 PM UTC+1, Goinnn wrote: >> >> 2013/12/9 Florian Apo

Re: Using setuptools to make django-admin.py runnable on Windows (#21340)

Just so we are all on the same page here (summarizing discussions from IRC etc): * We are not going to support setuptools and distutils, this makes the setupprocess difficult to debug and test imo. * Given Donald's "okay" we might switch to setuptools completely * There seems to be a bug in

Re: Forbidding double imports

Kill double imports with fire :þ (and now) -- 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 g

Re: django_bash_completion in Pypi Package

On Monday, January 6, 2014 7:57:50 AM UTC+1, Brett Nekolny wrote: > > Please let me know if anyone has thoughts regarding this proposed diff. I > would love to be able to get django_bash_completion from my pypi install of > Django, but that just doesn't seem to be possible without this fix. > >F

Re: Check Framework Feedback

On Thursday, February 6, 2014 12:31:43 AM UTC+1, Carl Meyer wrote: > > > However, I can see how this might be slightly contrary to expectation > > for Python developers generally. I'd be interested in hearing other > > opinions on this. > > I don't think there's a reason to require the argumen

Re: The unsettings project

On Tuesday, February 11, 2014 8:33:09 AM UTC+1, Aymeric Augustin wrote: > > On 11 févr. 2014, at 03:27, James Farrington > > > wrote: > > If you haven't heard about unsettings, it is an attempt to move away from > using the settings global. There was a discussion at djangocon (which I > wasn'

Re: Firebird backend for Django 1.6.x is updated (RC state)

Nice, can you also upload wheel packages? On Wednesday, February 12, 2014 2:19:11 PM UTC+1, mariuz wrote: > > Here are a few fixes for v1.6.x Release Candidate 1 commited into > master > > Fixed missing d

Re: DisallowedHost causes 500 errors.

Hi Cliff, just as a side note, the fact that you get those error in your inbox is also a sign of a missconfiguration of your webserver. The Django error is so to say a last resort, on a properly configured system those requests would never reach Django at all. Regards, Florian On Thursday, Fe

Re: #19182 backport request

Hi, as Tim noted on the ticket, we are not going to backport this as per our policy. Cheers, Florian On Friday, February 14, 2014 1:53:21 PM UTC+1, Chris Wilson wrote: > > Hi all, > > I just ran into bug #19182 : > > ModelAdmin filtering didn't wor

Re: The unsettings project

Hi, On Friday, February 14, 2014 3:18:08 PM UTC+1, Schuyler Duveen wrote: > > This work started at the Chicago DjangoCon sprint this past September. > Justin Holmes and I were talking to Adrian (and then roped in Jacob). > After discussing the problem and working out a possible way to move >

Re: #19182 backport request

On Friday, February 14, 2014 6:49:26 PM UTC+1, Chris Wilson wrote: > > I'm afraid that the documented feature is totally broken. > I have to disagree, the feature works as advertised as long as you don't use the combination of a custom filter and span relations. Regards, Florian -- You receiv

Re: GSoC query

On Saturday, February 15, 2014 5:01:09 PM UTC+1, anubhav joshi wrote: > > Well I will see what I put in my proposal..it will be based on > aggregation/annotation as well as improving the error message part as > before...I might now look to other things as well like improving tests as > well.

Re: Ticket #9?

On Sunday, February 16, 2014 3:13:28 AM UTC+1, Justin Holmes wrote: > > I didn't mean to suggest that it was nefarious. It's just that that > ticket had some... sentimental value. ;-) > I am pretty sure it's implemented by now: http://web.archive.org/web/20060105063700/http://code.djangoproj

Re: Using namedtuple instead of pure tuples

On Saturday, February 22, 2014 5:24:39 PM UTC+1, Adam Kaliński wrote: > > What do you guys think? > Sounds good, you might check if namedtuple has negative performance effects (I doubt it, but who knows). The reason we didn't add it yet is that it just exists since 2.6. cheers, Florian -- Yo

Re: GSOC 2014 Project Proposal

To me the Djangobook is basically (sadly) a dead resource, developing sample projects against the content/topics of Djangobook is not really a GSOC project imo. On Saturday, February 22, 2014 1:36:30 PM UTC+1, Devashish Badlani wrote: > > I have been an Ex technical editor at Brogels,I have revi

Re: GSOC 2014 Project Proposal

Hi, On Saturday, February 22, 2014 5:47:00 PM UTC+1, Devashish Badlani wrote: > > Every beginner I feel first starts with TheDjangoBook itself,he may switch > to some other source later. > Every beginner I see in #django starts with the tutorial as they should. > I feel keeping the book updat

Re: [GSOC 2014] Project Idea

Hi, I am not really sure what you are trying to propose here; generally a proposal should look something along the lines of https://groups.google.com/d/msg/django-developers/CD7OrkJ63zc/VRv2igHJxyIJ -- eg you'll have to do some research on the topic and write up a proper proposal. Cheers, Flo

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Hi Akshay, On Thursday, February 27, 2014 8:50:32 PM UTC+1, Akshay Jaggi wrote: > > *Why Py.Test?* (http://pytest.org) > >1. Widely Used > > So is nose and unittest, you'll need to add a bit more info to such statements. > >1. Better reporting > > Better how exactly? > >1. Distrib

Re: index_together should also have the same convinience as unique_together

Hi, there is no need to mail django-developers when you open a PR -- we do monitor the relevant lists. Cheers, Florian -- 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

Re: my admin theme

Hi, On Monday, March 3, 2014 11:35:31 PM UTC+1, adam spence wrote: > > I was wondering what you thought of my proposal to contribute my bootstrap > admin theme? > If you are refering to https://groups.google.com/d/msg/django-developers/0fD9zGtOhMg/vAdAOvxikFAJ -- you already got the answer of o

Re: requiring login to perform Trac actions?

On Tuesday, March 4, 2014 8:39:36 AM UTC+1, Anssi Kääriäinen wrote: > > I'd like to have some security against reporting as somebody else. > Currently one can report or comment anonymously and mark reporter as core > committer. This is too easy to abuse. +1 for requiring login. At least > for

Re: [GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.

Hi Alexey, On Wednesday, March 12, 2014 7:52:59 PM UTC+1, Алексей Сидаш wrote: > > Russian localization of django admin is poor. It is even worse then my > English :D. > How so? Can you provide a few examples -- I know that numbering can be a problem for Russian translations, but that's hardly

Re: Add support for get_or_none?

On Friday, March 14, 2014 4:50:49 PM UTC+1, Michael Manfre wrote: > > On Fri, Mar 14, 2014 at 11:15 AM, Cal Leeming [Simplicity Media Ltd] < > cal.l...@simplicitymedialtd.co.uk > wrote: >> >> >>> .get(or=None) (of some description) would be my preference, but even >>> that is ugly and confuse

Re: Add support for get_or_none?

On Thursday, March 20, 2014 2:01:25 PM UTC+1, Cal Leeming [Simplicity Media Ltd] wrote: > > I'll give it a couple more days for a BDFL to gives the thumbs up/down. > Well, we don't have BDFLs anymore and Shai already said he is -0 on it, count me in with a relatively strong -0 too. I'd be a bit

Re: [GSoC] Proposal. Translation of admin.

Hi Alexey, first of all I hope you are aware that the deadline for proposal submission is today. That said, applications require a solid proposal similar to https://gist.github.com/chrismedrela/82cbda8d2a78a280a129 (length and structure wise). If this email is intended to be your proposal, I am

Re: Migrations in Django 1.7 make unit testing models harder

On Tuesday, March 25, 2014 7:14:55 PM UTC+1, Andrew Godwin wrote: > > Yes, the new behaviour is by design, in the sense that the workaround you > mentioned will be deprecated in 1.9 (along with all syncdb-related > functionality). > What exactly will get deprecated here? -- You received this m

Re: Migrations in Django 1.7 make unit testing models harder

On Tuesday, March 25, 2014 9:12:42 PM UTC+1, Andrew Godwin wrote: > > So, the functionality whereby you can have apps which do not use > migrations (i.e. that use the old creation backends) is meant to go away in > 1.9. > Uhm, strong -1 here unless you have really convincing arguments, I really

Re: Proposal for prepared statements API

On Tuesday, March 25, 2014 11:57:51 PM UTC+1, Curtis Maloney wrote: > > Firstly -- can we assume anyone using this feature is not a complete > novice, and so will take the caveats mentioned into consideration? > Yes > Yes, prepared statements are local to their connection/session. And would

Re: Revisiting multiline tags

Technically I'd think only core devs would vote. So neither here or there would make a diff imo. P.S.: That said I am not sure we have a formal policy on how we act on DEPs yet (or maybe I should just read DEP 001 more carefully ;)) Cheers, Florian On Wednesday, April 30, 2014 4:02:26 AM UTC+2

Re: Feature request: ttl method for cache

Hi Russ, On Tuesday, May 6, 2014 2:54:52 AM UTC+2, Russell Keith-Magee wrote: > > As far as the NotImplemented bit goes - I'd rather see this implemented > for all officially supported backends, rather than only one backend. The > only exception to this would be if there is a fundamental technic

Re: Great Wall of DEP

Hi, On Thursday, May 8, 2014 2:13:52 PM UTC+2, Carl wrote: > > Just noticed this message, and the DEP PRs are still open a week later. > Can someone shuffle this along, please? > We are in the final stages of 1.7, I personally would rather focus on that first. -- You received this message

Re: "Master/slave terminology" (was: Master/slave trolling pull request accepted to django master branch)

On Tuesday, May 27, 2014 4:24:51 PM UTC+2, Meira wrote: > I appreciate your reply very much! And sure it's not wise to rename things > every time someone asks for it, even when it's a lot of people. But same > applies to the original renaming commit, doesnt it? > Yes and no, we trust our comm

Re: "Master/slave terminology" (was: Master/slave trolling pull request accepted to django master branch)

On Tuesday, May 27, 2014 5:38:23 PM UTC+2, Meira wrote: > > This second commit was discussed in a Trac ticket and everyone (even you!) >> was welcome to give their opinion. >> > > That's all nice and good, but why is the discussion taking the course of > whether or not we're accepting the seco

Re: Add an extra parameter to 'static' tag

Hi Renato, On Sunday, June 1, 2014 3:26:06 AM UTC+2, Renato Oliveira wrote: > > I open sourced the > modification we did (4 or 5 lines plus tests), and was about to send it to > pypi and wondered if it is an improvement to do on Django itself.

Re: Add an extra parameter to 'static' tag

Hi Renato, On Sunday, June 1, 2014 4:36:55 PM UTC+2, Renato Oliveira wrote: > > On Sunday, June 1, 2014 3:26:06 AM UTC+2, Renato Oliveira wrote: >>> >>> I open sourced the >>> modification we did (4 or 5 lines plus tests), and was about to send

Re: Why not Single Table Inheritance?

On Wednesday, June 11, 2014 2:16:06 AM UTC+2, Craig de Stigter wrote: > > I reserve judgment on whether STI should be included in core. It works > fine in a third-party app. Some better support for it in core would be > helpful, since currently I'm relying on some unsupported stuff that the >

Re: Migrations and Reusable Apps

On Tuesday, June 24, 2014 6:07:05 AM UTC+2, Sebastian Vetter wrote: > > I appreciate the offer and will gladly take it :) I'm currently in the > middle of a migration to Django 1.7 incl. backwards-compatibility. I'm > collecting questions about best practises right now and would love to > get

Re: collectstatic - override default ignore list

I see a point in ignoring hidden and swap files by default. CSV is imo something which shouldn't be used anymore and as such shouldn't be a default. Given that ignoring hidden and swap files should cover 80% of the use cases, I don't see much point in a new setting. Cheers, Florian On Tuesday,

Re: Response Fixes

On Wednesday, July 2, 2014 3:36:22 PM UTC+2, Łukasz Rekucki wrote: > > It doesn't just alter it, but makes it conform to HTTP standard. While > most browsers will accept relative urls, I don't think Django should > sacrafice backwards compatibility for an arcane CGI feature. Internal redirects

Re: modelformset_factory and unique_together don't always validate unique fields

Hi Jon, To me this is no shortfall but expected and good behaviour, including other fields in the validation (i.e. fields not on the form) would be very confusing. Where would errors show up? Also, even if we find a place to show the errors, the user is (usually) in no position to correct them

Re: modelformset_factory and unique_together don't always validate unique fields

On Thursday, July 3, 2014 3:03:25 PM UTC+2, Jon Dufresne wrote: > > > Also, even if we find a place to show > > the errors, the user is (usually) in no position to correct them (after > all, > > there is no field he could change to fix it). > > I don't follow. In my specific example the user

Re: Per-country URLs

On Tuesday, July 8, 2014 4:42:45 PM UTC+2, Aymeric Augustin wrote: > > Surprisingly, the call to get_language() is in RegexURLResolver, not in > LocaleRegexURLResolver. That's at least a code smell and possibly a flaw in > the current implementation. > Yes, I was surprised by that too when I d

Re: use semantic versioning after 2.0?

On Monday, July 14, 2014 9:50:53 PM UTC+2, Aymeric Augustin wrote: > [snip] +1, please leave it there -- 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 djang

Re: Documentation enhancement for class based GenericView

Hi Wayne, On Wednesday, July 16, 2014 3:48:34 PM UTC+2, Wayne Ye wrote: > > >- When GET a resource, I want to do a counting job to record total hit >on this specific resource > > Override dispatch or get, count and delegate to the parent. > >- When a posted form is invalid, I wa

Re: [New feature request] Prefer:Safe request header

Hi, On Wednesday, July 23, 2014 1:58:26 PM UTC+2, S4mmael wrote: > > It would be really nice to have some mechanism intended to work with this > header in Django. A kind of miidleware or a decorator maybe. > What's wrong with "if request.META.get('prefer') == 'safe'"? Cheers, Florian -- You

Re: Updating the organization of the Django Project

+1 On Wednesday, July 23, 2014 3:30:13 PM UTC+2, Aymeric Augustin wrote: > > Hello, > > I’ve been working on updating our organization: > https://github.com/django/django/pull/2947 > > This proposal attempts to address several issues with our current > organization. There’s no short version an

Re: Django and BREACH (remember that?)

Hi, On Monday, August 4, 2014 3:15:15 AM UTC+2, Adam Brenecki wrote: > > So, a while ago, BREACH happened, and Django's CSRF implementation was > vulnerable, as was Rails'. The paper that discussed it described a > mitigation (and a Rails patch had already been made), so I implemented that > sa

Re: Django and BREACH (remember that?)

On Monday, August 4, 2014 11:01:14 AM UTC+2, Adam Brenecki wrote: > > What is wrong with xor+base64? Not that Vigenère cipher is complex, but we >> have a pretty hard stance against implementing "crypto" on our own. >> > > Nothing, really; that's probably what I would have used had FunkyBob not

Re: Django and BREACH (remember that?)

On Monday, August 4, 2014 4:21:43 PM UTC+2, Michael Mior wrote: > > This looks good, although it seems like there should be a config setting > as I could imagine some use cases where the application expects the token > not to change in this way. I'm not sure how common this and whether or not >

Re: Proposal: Password Validity Layer

On Tuesday, August 5, 2014 8:45:05 PM UTC+2, Collin Anderson wrote: > > Could we handle it with model validation on a custom user model? Maybe add > a validate_password() method on the user model? I don't think so, using a custom user just for password validation is way to much work given that

Re: Proposal new Django Admin css style

On Tuesday, August 12, 2014 12:26:45 PM UTC+2, Thiago Avelino wrote: > > Not a Django core part of the topic, as it was? > But still a valid point. That said, I find the current style way nicer than the proposed one. Cheers, Florian -- You received this message because you are subscribed to th

Re: Support HTML5 syntax

That is not just XHTML but perfectly valid HTML5. Cheers, Florian On Sunday, August 17, 2014 8:30:33 AM UTC+2, noegry wrote: > > Could Django provides a way to render forms in HTML5 syntax? It now render > forms in XHTML syntax as > > Or could it in the settings provides an option as USE_HTML5

Re: Would AssertMaxQueries (similar to AssertNumQueries) be a useful addition

I am not so convinced, what would you put in as the upper limit? While preventing n+1, it still requires you to know what n in this testcase is and changing n can lead to funny errors. Currently we are documenting (hopefully) how those query counts come together, so it's clear what's happening

Re: Support HTML5 syntax

On Sunday, August 17, 2014 7:33:17 PM UTC+2, noegry wrote: > > It might cause issues when templates are using HTML5 syntax but forms are > using XHTML syntax? > The forms are not using XHTML syntax per se, they are valid HTML5 and valid XHTML! -- You received this message because you are sub

Re: Proposal: Password Validity Layer

Validation errors are only caught inside form validation. Forms set the password usually in save, not in clean, so I don't think that patch covers it (or at least the relevant forms have to call validate_password in clean too) On Monday, August 18, 2014 5:31:05 PM UTC+2, Keith Hackbarth wrote:

Re: 1.7 release?

On Tuesday, August 19, 2014 10:01:22 AM UTC+2, Stephen Burrows wrote: > What's the status? Good so far, release will be there soon (tm). Is there anything that community members can do? > Yes, test it heavily -- especially migrations :) -- You received this message because you are subscrib

Re: 1.7 release?

On Tuesday, August 19, 2014 10:01:22 AM UTC+2, Stephen Burrows wrote: > > Is there anything that community members can do? > Oh, and reviewing unreviewed tickets, so we can make sure there are no new release blockers. Cheers, Florian -- You received this message because you are subscribed t

Re: pre_save signal on Inherited Model?

Hi Leo, On Wednesday, August 20, 2014 2:48:07 AM UTC+2, Leo Hillman wrote: > > — pre_delete registered on parent model: fired > — pre_save registered on parent model: not fired > That sounds inconsistent at least. Can you open a ticket for that? Cheers, Florian -- You received this message

Re: Using test.client.Client.post with body?

On Tuesday, August 26, 2014 8:45:03 AM UTC+2, ryan liang wrote: > > """ > payload = ... your payload ... > stream = StringIO(payload) > client.post(url, > CONTENT_TYPE='text/json', > CONTENT_LENGTH=len(payload), > wsgi.input = stream) > """ > It does not work. > Obviously not, wsgi.inp

Re: integrating django-secure

On Thursday, August 28, 2014 2:44:08 PM UTC+2, Tim Graham wrote: > > Regarding settings, would it be preferable to move them into a single > dictionary setting called something like SECURITY_MIDDLEWARE_CONFIG? > Definitely. -- You received this message because you are subscribed to the Google

Re: integrating django-secure

On Saturday, August 30, 2014 12:58:18 PM UTC+2, Aymeric Augustin wrote: > > If it weren’t for backwards compatibility, we could recursively merge > dicts from user settings into defaults settings. For example > https://github.com/django/django/pull/3138 achieves that in > override_settings. >

Re: integrating django-secure

On Saturday, August 30, 2014 1:58:07 PM UTC+2, Aymeric Augustin wrote: > > On 30 août 2014, at 13:39, Florian Apolloner > wrote: > > > And what would that give us? if I want override FOO['BAR'] where from > would I override FOO with that merging behavior in plac

Re: integrating django-secure

On Saturday, August 30, 2014 2:48:10 PM UTC+2, Tim Graham wrote: > > If base.py adds CONTENT_TYPE_NOSNIFF and prod.py wants to add > HSTS_SECONDS, it would look like this: > Oh, that makes sense, I was so focused on "extending" that I didn't see that base.py could define a minimal dict itself

Re: Please don't kill the ecosystem

Hi Pkl, On Monday, September 1, 2014 10:45:30 PM UTC+2, Pkl wrote: > > In random order, I stumbled upon: > - removal of django.conf.urls.defaults > - removal of markup contrib lib (adios built-in RST support) > - removal of request.raw_post_data (thus breaking about all existing > webservice libs

Re: [RFC] Python 3 and MySQL

On Tuesday, September 9, 2014 9:22:10 AM UTC+2, Naoki INADA wrote: > > Failed to install index for admin_views.PrePopulatedPostLargeSlug > model: (1071, 'Specified key was too long; max key length is 767 bytes') > Welcome to the wonderful world to mysql, afaik this is a warning and not an er

Re: [RFC] Python 3 and MySQL

http://djangoci.com/ disagrees with you :) Would have to check the specific mysqldb version. -- 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-develo

Re: [RFC] Python 3 and MySQL

> > $ python -V > Python 2.7.8 > (mysql2)[inada-n@MBA:~] > $ pip list > MySQL-python (1.2.5) > pip (1.5.6) > setuptools (3.6) > wsgiref (0.1.2) > > On Tue, Sep 9, 2014 at 5:18 PM, Florian Apolloner > wrote: > > On Tuesday, September 9, 2014 9:2

Re: Proposal: add a get_for_template method to ContextList

On Monday, September 15, 2014 3:24:19 PM UTC+2, germano guerrini wrote: > > I'd like to bump this. While there might be better solutions, I think the > issue is not so wacky after all. > To be honest, I don't see an issue here at all. What the view returns should end up in the template. If tags/

Re: mod_security SQL injection rules and Django cookies

Hi Nikolai, On Friday, September 19, 2014 1:50:33 PM UTC+2, Nikolai Prokoschenko wrote: > > 1. Has there been some security audit in the past which confirmed that > session ID handling inside Django is not vulnerable to SQL injection > attacks? > Nothing public that I am aware of, no. 2. Can I

Re: Django 1.7: inconsistent behaviour of the fail_silently option when using SMTP backend

Hi Marcin, can you please open a ticket for this? If you are up to it, a patch with tests would be superb! Thanks, Florian On Sunday, September 28, 2014 1:26:42 PM UTC+2, Marcin Nowak wrote: > > Hello, > > After sereral minutes while using new Django (1.7) in DEBUG mode, I've got > enigmatic e

Re: Storage engine aliases?

Hi Jeremy, To be honest I don't really see the gains (yet). How are those FILE_STORES supposed to handle the *_URL bits of those settings? Instances in settings are imo not going to fly, we should stay with strings to classes/instances there for now. So how would the 'static' or 'dynamic' insta

Re: Transaction management and atomic

On Wednesday, October 1, 2014 6:58:28 AM UTC+2, Anssi Kääriäinen wrote: > > Django does allow to continue the transaction if you explicitly choose > to do so. After handling the error, you must use set_rollback[1]. This > is useful for those rare cases where you want to continue after error in >

Re: Transaction management and atomic

On Wednesday, October 1, 2014 6:58:28 AM UTC+2, Anssi Kääriäinen wrote: > > Django does allow to continue the transaction if you explicitly choose > to do so. After handling the error, you must use set_rollback[1]. This > is useful for those rare cases where you want to continue after error in >

Re: 1.8 release planning

On Saturday, October 18, 2014 1:17:58 AM UTC+2, Josh Smeaton wrote: > > I was thinking along the lines of a one page common upgrade issues that > summarised the back-compat changes from the previous releases, separated > under each release header. > We already have on page per release for tha

Re: Google Analytics API

Hi, this mailinglist is about the development of Django itself, you should write to django-users. Cheers, Florian On Wednesday, October 22, 2014 8:33:30 AM UTC+2, Muhammed Tüfekyapan wrote: > > Hi Everyone, > > > > I want to make an app. User come on site, they signed in and give access > to

Re: Suggestion for @cache_page compatiblity with jQuery JSONP

Uhm, I don't think you can ignore the callback, isn't the callback what's included in the response? As such for proper function the callback can't be ignored. Cheers, Florian On Wednesday, October 22, 2014 7:16:48 AM UTC+2, Luke Dupin wrote: > > Anyone that has used @cache_page with jquery's JS

Re: Websockets... again

On Tuesday, October 28, 2014 11:37:15 PM UTC+1, mpaolini wrote: > > What if we do it with asyncio? > It is 3.4 only, WSGI still has no support for Websockets and the API would change drastically… -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Deprecating logout via GET

On Friday, February 28, 2020 at 5:08:07 PM UTC+1, Maher, Brian wrote: > > Are any current browsers dumb enough to prefetch logout links these days? > I would assume that most prefetch algorithms are smart enough to not > pre-fetch these. > Not sure what heuristics browsers use. I have also s

Re: Deprecating logout via GET

I found an example on stackoverflow on how we could do this in the admin without JS (with a bit of styling): https://stackoverflow.com/a/33880971 -- I personally would prefer it if we would not need javascript for a fundamental functionality like this. On Saturday, February 29, 2020 at 9:26:23

Re: Deprecating logout via GET

UX wise the intermediary page is annoying. So if we can just provide some docs and upgrade notes I'd be fine with just dropping the get part. On Thursday, March 5, 2020 at 5:40:25 PM UTC+1, René Fleschenberg wrote: > Hi, > > On 04.03.20 12:13, Sam Willis wrote: > > Why not have the logout link

Re: Discuss ticket 20264: URLValidator should allow underscores in local hostname

Hi Adam, On Wednesday, March 25, 2020 at 7:27:58 PM UTC+1, Adam Johnson wrote: > > I think that would make Florian happy, although it *has* been seven years > since his closing comment on the ticket. > You should know me better :D No this would not make Florian happy and he is still against it.

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

On Thursday, March 12, 2020 at 6:16:31 PM UTC+1, Dawid Czeluśniak wrote: > > I think that the root question here is: should we allow users to create > passwords from anything that is not str? > I would reduce it to allow strings & bytes and am willing to review a patch and push it through. It

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

oh, I somehow missed that. thanks for the heads-up. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsu

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

On Wednesday, May 6, 2020 at 5:49:40 PM UTC+2, Adam Johnson wrote: > > Would just like to point out - that's not the proposal. The proposal is to > rename the existing request.POST to request.form_data, which is based on > parsing application/x-www-form-urlencoded data from request.body. Browse

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

On Saturday, May 9, 2020 at 1:41:41 PM UTC+2, Aymeric Augustin wrote: > > - Users who don't know that GET queries mustn't have side effects and who > don't want to bother will have an incentive to use a POST query to get the > data in form_data; this is the safe option with regards to CSRF; >

Re: Django Version 3.2 Roadmap

On Wednesday, May 13, 2020 at 4:40:55 PM UTC+2, Adam Johnson wrote: > > This looks good to me, it fits the preset release cadence. Although the > final release will be on "April fools day," it's something we've done > several times before. > While we might have done it (did we actually do that s

Re: Implement QuerySet.__contains__?

On Tuesday, June 2, 2020 at 11:28:34 AM UTC+2, Adam Johnson wrote: > > If you already fetched the queryset, `if obj in queryset` will make a new >> database query > > > I don't see why we couldn't implement __contains__ to do a walk through > _result_cache if it has been fetched? > we are doing

What's wrong with the jenkins testrun failing on ASGI (I think?)

Hi, do we have any idea what is happening on https://djangoci.com/job/pr-mariadb/database=mysql,label=mariadb,python=python3.8/6459/ ? It seems as if (mostly) the same set of tests is failing over and over. Is this ASGI/concurrency related? Cheers, Florian -- You received this message becau

Re: What's wrong with the jenkins testrun failing on ASGI (I think?)

Ok, so rebasing PRs to current master will fix this (leaving this here as note for others who run into this). On Tuesday, June 16, 2020 at 10:39:13 AM UTC+2, Mariusz Felisiak wrote: > > It's an issue with the asgiref==3.2.8, see > https://github.com/django/asgiref/issues/170. We temporarily pinn

Re: Overriding template blocks without copy/pasting entire template files

If you look at the mails beyond the first one, you will see that Josh & Carlton already came to that conlusion ;) On Tuesday, June 16, 2020 at 2:16:31 PM UTC+2, Arvind Nedumaran wrote: > > Could you elaborate on how this is different from extending a base > template and re-defining the necessary

Re: Overriding template blocks without copy/pasting entire template files

hours ago. :) > > Onward, > Arvind > > Sent from Outlook Mobile <https://aka.ms/blhgte> > > -- > *From:* django-d...@googlegroups.com < > django-d...@googlegroups.com > on behalf of Florian > Apolloner > > *Sent:* Tuesday, June 16,

Re: Making startproject's settings more 12-factor-y

Hi there, On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 kit@gmail.com wrote: > Personally, I think that *at minimum* providing Django-builtin "get from > env" helpers would be great; beyond that, I'd love to have them be > included around `DEBUG` and `SECRET_KEY` with the current values a

Re: Making startproject's settings more 12-factor-y

On Friday, June 26, 2020 at 12:11:34 PM UTC+2 re...@fleschenberg.net wrote: > There is a trade-off between security and development convenience here. > At the moment, the settings generated by manage.py startproject are > geared towards development (random default value for SECRET_KEY, DEBUG =

Re: Making startproject's settings more 12-factor-y

Hi Tom, On Friday, June 26, 2020 at 12:43:19 PM UTC+2 t...@carrick.eu wrote: > I do have a use-case where having a default SECRET_KEY makes things much > easier - docker. > > Normally you can't run management commands in a Dockerfile if there's no > secret key (and often other things) set, and

Re: Making startproject's settings more 12-factor-y

On Sunday, June 28, 2020 at 1:23:25 AM UTC+2 timog...@gmail.com wrote: > It seems like it could be insecure to move that to a system check as "For > performance reasons, checks are not run as part of the WSGI stack that is > used in deployment." (Also, it seems impossible to write a system che

Re: Making startproject's settings more 12-factor-y

ssues. On Sunday, June 28, 2020 at 10:27:44 AM UTC+2 Florian Apolloner wrote: > On Sunday, June 28, 2020 at 1:23:25 AM UTC+2 timog...@gmail.com wrote: > >> It seems like it could be insecure to move that to a system check as "For >> performance reasons, checks are not run as

Re: Should the docs suggest namespace packages?

There are also various issues in python itself like https://bugs.python.org/issue23882 -- so I strongly recommend against namespace packages unless you actually need them. On Monday, July 20, 2020 at 1:14:41 AM UTC+2 re...@fleschenberg.net wrote: > Hi, > > On 7/19/20 10:25 PM, Tim Graham wrote:

Re: Making startproject's settings more 12-factor-y

Comments like these are inappropriate for this mailing list. Stop spamming your whatsapp number all over the place. On Sunday, July 26, 2020 at 6:00:47 PM UTC+2 mithileshr...@gmail.com wrote: > ok whatsapp +918709440658 <+91%2087094%2040658> > > On Fri, 10 Jul 2020, 2:54 pm '1337 Shadow Hacker'

<    1   2   3   4   5   6   7   8   9   >