Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

I guess it would help to know how Safari's tracking protection does work (I do not own a Mac) -- it seems hard to imagine that an internal redirect on a page triggers the protection. In that sense it seems more like a ISP-problem like Adam pointed out. On Sunday, November 25, 2018 at 9:39:28 AM

Re: Removing Oracle from Django core in 3.0

Hi, I personally agree with Mariusz here. Oracle might have it's own quirks, but the same could be said for any database. Taking my experience with the ORM into account I do not think that Oracle requires much more work (if at all) than any other database. I think in the end it does not matter

Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

On Monday, November 26, 2018 at 10:28:07 AM UTC+1, Mat Gadd wrote: > > Florian, it's not strictly an "internal redirect on a page", but the > combination of being bounced from a different domain to our site, and their > our site immediately performing its own redirect. If the links were > dire

CSRF Middlware and usage of request attributes (META, csrf_cookie_needs_reset)

Hi there, I am considering rewriting and (hopefully) simplifying the CSRF middleware. While looking through the code I realized that we put stuff into request.META as well as attributes on the request object itself (csrf_cookie_needs_reset) for instance. Is there any reason why we do not stick

Re: CSRF Middlware and usage of request attributes (META, csrf_cookie_needs_reset)

Hi Adam, On Saturday, December 29, 2018 at 7:59:44 PM UTC+1, Adam Johnson wrote: > > since request.META is always there whilst attributes might not be if the > middleware aren't set up properly? > request.META is always there, but the keys inside there might not be. In that sense you have to do

Re: Listening for postgres NOTIFY with django.db - adding support for connection.fileno()

Hi, On Monday, December 31, 2018 at 12:38:31 PM UTC+1, Fábio Molinar wrote: > > Is this currently not supported or am I missing something? I though that > the django.db is kind of just a wrapper around the actual psycopg2 library. > So I wonder why I can't use the fileno() method on it. > djang

Re: Google Summer of Code 2019

On Thursday, January 24, 2019 at 4:01:00 PM UTC+1, Adam Johnson wrote: > > I'd be happy to help mentor a cross-DB JSONField, it's something I'd like > to see done so I can deprecate the one I maintain in Django-MySQL. > Not sure if GSOC changed that much, but it seems like somewhat small for a G

Re: revisiting the Python version support policy

FWIW, most of my problems with python version dependencies went away when I started to use a custom build on our servers. Allows easy upgrades and a good environment for our programs. On Friday, January 25, 2019 at 4:01:28 PM UTC+1, Dan Davis wrote: > > My employer is still using CPython 3.4.6 o

Re: Proposal: Track used headers and use that information to automatically populate Vary header.

While reading this thread https://code.djangoproject.com/ticket/19649 came to mind. I think most (if not all) from there basically is the same issue, even though that one just concerns itself with the Cookie header. I do not agree that request.headers is __now__ the single place for accessing h

Re: Use CDN for djangoproject.com

Especially cloudflare is a service we do not want to use. as for the docs only, does the mirror on rtd work better for you? They are probably behind a CDN. Cheers, Florian On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote: > > Hi, > > Is it possible to utilize a CDN service for d

Re: Post mortem on today's packaging error.

On Monday, February 11, 2019 at 11:01:55 PM UTC+1, Adam Johnson wrote: > > Jamesie’s suggestion to use CI is also valid but a bunch more work. I > guess the main advantage is you get a blank slate container to work in, > which a fresh checkout to a temp dir provides most of the gain for less >

Re: Use CDN for djangoproject.com

On Wednesday, February 13, 2019 at 11:25:37 PM UTC+1, Josh Smeaton wrote: > > Why do we not want to use Cloudflare? > Last time I checked (if one puts the full site behind cloudflare) you'd have nasty checks that usually triggers captchas for Tor users etc. From what I can tell there was no wa

Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

Hi Collin, it is not (just) about links, it is mainly about stylesheets/js. But we can set a header on that view: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy This should work for every browser != IE/Edge. Cheers, Florian On Friday, February 22, 2019 at 9:35:53 PM

Re: Use CDN for djangoproject.com

to everything. The reason is that we offer the download of the release >>>>>>>> artifacts from the djangoproject.com website. And we would like to >>>>>>>> ensure that the TLS termination happens by us and not some random >>>>>>>> service >&

Re: Official Django Docker Container Deprecated

On Tuesday, February 26, 2019 at 8:39:34 AM UTC+1, Alexander Lyabah wrote: > > I found out that official django container is deprecated. Why you don't > want to support it? > There was never one to begin with. -- You received this message because you are subscribed to the Google Groups "Dja

Re: Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

I am wondering if this also results in https://code.djangoproject.com/ticket/29975 or if this is just a result of their tracking protection. All in all it would be great to know what Safari actually does… (sadly I do not own a Mac :/) I'll dig through #30250 soon. > - User will not be logged i

Re: Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

Hi Flavio, On Friday, March 15, 2019 at 2:56:16 PM UTC+1, Flávio Junior wrote: > > > shouldn't httponly yes/no control whether JS can read the data? > > Yes. But, on Django, the default is httponly false for CSRF cookie. > So even without httponly, Safari doesn't allow JS to read the CSRF cookie.

Re: Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

On Monday, March 18, 2019 at 10:50:17 PM UTC+1, Flávio Junior wrote: > > What are the next steps? > A warning at the docs for these settings? > I guess that is the big question. We'd have to remove the warning "soonish" again I guess once safari is fixed (after all one wants the added security

Re: Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

On Thursday, March 28, 2019 at 11:37:21 PM UTC+1, Flávio Junior wrote: > > So new iOS and Mac minor versions were launched, but issue is still there. > Created a new bug ticket on Webkit and they're being able to reproduce > better the problem: https://bugs.webkit.org/show_bug.cgi?id=196375 > Ho

Re: Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

riday, March 29, 2019 at 8:42:34 AM UTC+1, Florian Apolloner wrote: > > > > On Thursday, March 28, 2019 at 11:37:21 PM UTC+1, Flávio Junior wrote: >> >> So new iOS and Mac minor versions were launched, but issue is still there. >> Created a new bug ticket on Webkit

Re: 2020 Authentication Initiativ

Hi Joe, uff you are bringing up a hard topic :) Yes I absolutely would like Django to have better support for WebAuth (u2f-like tokens at least), and probably another one or two (I'd keep the scope for support in Django small though once we know that the API works). Getting this actually imple

Re: 2020 Authentication Initiativ

Hi Joe, On Thursday, April 11, 2019 at 4:56:05 PM UTC+2, Johannes Hoppe wrote: > > @Florian, since I had so many PRs pending review, I had to find other ways > to cause chaos ;) > Hehe probably, the autocomplete stuff is on my todo for the sprints (and selenium is mainly waiting for a merge).

Re: Converting serve static to class base views

Hi, as written on the ticket already you have to present __why__ and __what__ your class based view makes easier. As it currently stands I cannot see anything which you couldn't also achieve by "inheriting" the function based view. Cheers, Florian On Thursday, April 11, 2019 at 11:05:36 PM UT

Re: 2020 Authentication Initiativ

Hi, On Friday, April 12, 2019 at 8:06:21 PM UTC+2, Johannes Hoppe wrote: > > I went with the hardest possible way, NO password, NO username. Just one > time passwords send via email or SMS. Similar to Django’s password reset > function. > I do not think that is the hardest possible way and as y

Re: 2020 Authentication Initiativ

On Saturday, April 13, 2019 at 1:07:39 PM UTC+2, Florian Apolloner wrote: > > You could have reused https://github.com/aaugustin/django-sesame for the > signing stuff :) > Ok django-sesame goes into a different direction but might still be worth to look at it. -- You received

Re: Proposal to format Django using black

As expressed at Djangocon Europe, I am hugely in favor for adopting black. If we choose to do this there are a few things to consider: * Line-length, we probably want to stay at 119 I guess * String normalization, I'd be in favor of following black defaults here, but I am open to be convinced

Re: Add to QuerySet method `one` that acts as `first` but without ordering

qs.order_by().first() should do what you want and is not worth adding .one() Cheers, Florian On Saturday, April 13, 2019 at 5:48:29 PM UTC+2, alTus wrote: > > Hello. > > Please consider if that proposal can be useful not only for me :) > > `QuerySet.first` is quite useful shortcut but its drawbac

Re: Proposal to format Django using black

Hi, On Saturday, April 13, 2019 at 9:41:38 PM UTC+2, Berker Peksağ wrote: > > I came here to say exactly this. Django's codebase is already pretty > consistent with its own style and I think having a usable "git blame" > is much more important than starting to use a new code formatter. I am n

Re: Proposal to format Django using black

On Saturday, April 13, 2019 at 8:23:13 PM UTC+2, Adam Johnson wrote: > > I’d like to see gradual roll out (one module at a time? One rule at a > time?) to spread the work of reformatting all the in-flight patches. > My thoughts initially. But then I realized that it would be easier for tooling i

Re: Add to QuerySet method `one` that acts as `first` but without ordering

On Saturday, April 13, 2019 at 10:58:24 PM UTC+2, alTus wrote: > > I've posted the source code if `first`. You can see there that if qs is > not ordered then ordering by pk is added. > It's the main point of this issue btw. > Oh I didn't realize that first enforces ordering. Yet another function

Re: Add to QuerySet method `one` that acts as `first` but without ordering

Hi, while your arguments for adding `.one` are all good and well, I think adding yet another function will add quite some confusion and will make arguing harder imo. As a middleground I could imagine adding an `ordered=True/False` argument to first to turn off ordering as needed. This will als

Re: Proposal to format Django using black

Hi, On Sunday, April 14, 2019 at 1:04:22 AM UTC+2, Berker Peksağ wrote: > > I always do it to not bother > contributors with these changes, especially if they are new to the > project. > This is imo not something that scales well. Also it is not something I want to pay our fellows for, I rath

Re: Proposal to format Django using black

On Saturday, April 13, 2019 at 10:21:48 PM UTC+2, James Bennett wrote: > > But we already have and enforce a style guide, and some parts of it are > things Black can't auto-enforce. > We do? I mean sure, we do have a styleguide, but enforcing it? It all depends on how well our fellows (manual

Re: Proposal to format Django using black

Hi Christian, I think you are making a good argument here. On one hand short-comings in our tool chain should not block us from making changes. On the other hand, we do have to live with them -- so having at least some technical solution towards the "git blame" issue is needed. I guess the chro

Re: Proposal to format Django using black

Hi, On Sunday, April 14, 2019 at 10:22:46 AM UTC+2, Curtis Maloney wrote: > > Can such a tool be automated into, say, github in a way that doesn't > create extra commit noise? > Probably, but after blacking (is that even a word ;)) the codebase once there shouldn't be much commit noise. I sid

Re: Proposal to format Django using black

Hi Simon, On Monday, April 15, 2019 at 1:02:49 AM UTC+2, charettes wrote: > > and there's no way to turn off only this form of string normalization, > it's all or nothing. > So the black --help output lists: -S, --skip-string-normalization Don't normalize string quotes or prefixes. Or does tha

Re: Proposal to format Django using black

Hi, as Adam points out 1.0 is on it's way. My mails were written with that knowledge and assumption, sorry for not making this clear. I did actually had in mind to wait till it is out of beta -- which is most likely before we finished our discussions :D Cheers, Florian On Monday, April 15, 201

Re: Proposal to format Django using black

Hi Emil, this would only affect Django 3.0 which supports only python3.6 -- as such you couldn't even run Django on those systems anyways. Cheers, Florian On Tuesday, April 16, 2019 at 10:12:20 AM UTC+2, Emil Madsen wrote: > > Hello, > > I'm not sure if it's relevant for the discussion, but bla

Re: Proposal to format Django using black

On Wednesday, April 24, 2019 at 1:25:55 PM UTC+2, Josh Smeaton wrote: > > Black does not support disabling formatting by block with a comment. It > removes all choice except for the upfront choices of length and string > normalisation. > It does, "# fmt: off" and "# fmt: on" can be used -- Y

Re: Deferring "Sign the CLA"

I think the question is if we need those at all. This is something the DSF should be able to answer. On Saturday, April 27, 2019 at 2:42:36 PM UTC+2, Carlton Gibson wrote: > > Hi all. > > The CLA makes two appearances in the docs: > > * New contributors: First Steps >

Re: Deferring "Sign the CLA"

On Saturday, April 27, 2019 at 7:26:58 PM UTC+2, Carlton Gibson wrote: > > Right now I just wanted to move it down the page. > By all means do so… I vaguely remember talking to Jacob when I saw him last and his stance on it was that we either do not need the CLA at all anymore or something li

Re: Proposal to format Django using black

On Thursday, May 2, 2019 at 6:15:50 PM UTC+2, matthew.pava wrote: > > Just a thought: If Django were to adopt black (and I'm not saying it > should), shouldn't it wait until it is out of the beta classification? > Please read the dep: https://github.com/django/deps/blob/master/draft/0008-blac

Re: Autocomplete fields and cleaned_data

On Monday, May 13, 2019 at 8:25:56 PM UTC+2, Melvyn Sopacua | 3YOURMIND wrote: > > It seemingly removes the field from self.cleaned_data, which means we can > no longer validate it. > If that is the case it is a bug I'd say. -- You received this message because you are subscribed to the Goo

Re: Ideas for a new DEP on long-term Django API compatibility

Hello World, On Sunday, June 30, 2019 at 9:24:05 AM UTC+2, Aymeric Augustin wrote: > > As an experiment, let's just consider the first backwards-incompatible > change from the latest release: > https://docs.djangoproject.com/en/2.2/releases/2.2/#admin-actions-are-no-longer-collected-from-base-mo

Re: Fuzzing Django at Google OSS-Fuzz

Hi Guido, wow. That would be very much appreciated. security@dp is just a google mailing list I fear. If you added me, would it be possible that I manage the other email addresses, or would you have to do that all? Also for now please do not add anyone without my sayso, I'll get in touch with y

Re: Translation templatetag aliases

Not opposed to changing it, but would make {% translateblock %} more sense than {% blocktranslate %}? On Saturday, July 27, 2019 at 10:51:35 AM UTC+2, Aymeric Augustin wrote: > > Hello, > > I'm in favor of adding support for {% translate %} and {% blocktranslate > %} and switching the Django doc

Re: django-admin startproject settings.py has some security holes

On Thursday, October 10, 2019 at 9:41:53 PM UTC+2, Bobby Mozumder wrote: > > Additionally, startproject should add a .gitignore in the root directory > to not include development/staging/production settings files. > I am very much against creating a .gitignore as part of startproject. Also I

Re: GitHub Actions

Hi, yes I had the same thought yesterday. I think trying with linters first should be an easy low hanging fruit (and to get a feeling for it). Tests in general might get a bit harder. Cheers, Florian On Thursday, October 31, 2019 at 10:30:10 AM UTC+1, Johannes Hoppe wrote: > > Hey there, > > I

Re: GitHub Actions

randomly fail and I can't restart them. > I think the ability to just restart actions as a user is going to be a > major improvement to the current workflow. > > On Thursday, October 31, 2019 at 6:36:24 PM UTC+9, Florian Apolloner wrote: >> >> Hi, >> >> ye

Re: GitHub Actions

On Thursday, October 31, 2019 at 11:08:49 AM UTC+1, Tom Forbes wrote: > > 1. How do we support Oracle? > For now we don't 2. Can we (or do we want to?) unify it somehow with docker-box? > If it makes sense yes, if it makes the actions horribly complex and it would be more action-like in anoth

Re: GitHub Actions

On Thursday, October 31, 2019 at 2:33:29 PM UTC+1, Florian Apolloner wrote: > > > > On Thursday, October 31, 2019 at 11:08:49 AM UTC+1, Tom Forbes wrote: >> >> 1. How do we support Oracle? >> > > For now we don't > Ui, seems like we can start using o

Re: GitHub Actions

On Wednesday, November 6, 2019 at 8:43:21 AM UTC+1, Shai Berger wrote: > > Is there benefit enough in GitHub Actions (over Jenkins) to justify a > move from an open-source based solution? > Yes, less server costs (even if sponsored). Less things to maintain for us (Jenkins is a beast). Better

Re: GitHub Actions

On Wednesday, November 6, 2019 at 4:48:11 PM UTC+1, Tom Forbes wrote: > > The usage limits are documented here: > https://help.github.com/en/github/automating-your-workflow-with-github-actions/about-github-actions#usage-limits. > > I’m not sure how they apply to organisations (maybe just “free

Re: Vote on Jira as bugtracker

Ditto. On Wednesday, January 6, 2016 at 2:43:44 PM UTC+1, Marc Tamlyn wrote: > > Yeah, this is a non-starter for me. All bug trackers are bad, we should > stick with the bad one we are used to. > > Marc > > On 6 January 2016 at 13:26, Victor Sosa > > wrote: > >> To answer you question: >> There

Re: slow migrations

Also, is there any chance that I can get access to this project to profile a little bit more and identify some hotspots? On Thursday, January 7, 2016 at 9:10:26 PM UTC+1, Florian Apolloner wrote: > > Just looking at the topmost three entries: > *_expire_cache* spends 18 second in del

Re: Vote on Jira as bugtracker

Hi Yamila, On Thursday, January 7, 2016 at 2:22:21 PM UTC+1, Yamila Moreno wrote: > > I just wanted to let you know that me or anyone in our team would be glad > to answer any question about the product, saas or installation, migrating > issues or anything related. No strings attached, of course

Re: re-thinking middleware

On Friday, January 8, 2016 at 12:51:25 PM UTC+1, Markus Holtermann wrote: > > Nitpicking, I would also name the settings variable MIDDLEWARES (i.e. > plural) as it is a list of middlewares, not just one. > Yes, my thought too. On January 8, 2016 10:31:49 PM GMT+11:00, Curtis Maloney < cur...

Re: re-thinking middleware

Mhm, I currently see no easy way to give *get_response* access to the list of middlewares like done in https://github.com/django/django/pull/5591/files#diff-dbd7d9159676b15fc9a096b0adb919e9R122 and following lines. The reason is that providing *get_response* at setup/init time means it has to

Re: re-thinking middleware

I've gone ahead and pushed a new commit to match the spec (not tested yet, but hey :D). On Friday, January 8, 2016 at 3:29:01 PM UTC+1, Florian Apolloner wrote: > > Mhm, > > I currently see no easy way to give *get_response* access to the list of > middlewares like done in

Re: re-thinking middleware

nuary 8, 2016 at 3:29:01 PM UTC+1, Florian Apolloner wrote: > > Mhm, > > I currently see no easy way to give *get_response* access to the list of > middlewares like done in > https://github.com/django/django/pull/5591/files#diff-dbd7d9159676b15fc9a096b0adb919e9R122 > > an

Re: re-thinking middleware

PR1 (allows changing the middlewares during the middleware run): https://github.com/django/django/pull/5591 PR2 (static middleware chain, seems simpler and probably the way to go): https://github.com/django/django/pull/5949/ On Friday, January 8, 2016 at 4:55:08 PM UTC+1, Florian Apolloner

Re: PostGres 9.5 Upsert

Absolutely! On Saturday, January 9, 2016 at 1:13:26 AM UTC+1, bliy...@rentlytics.com wrote: > > Hey Guys, > > Postgres 9.5 has added the functionality for UPSERT aka update or insert. > Any interest in aligning UPSERT on the db layer with the get_or_create or > update_or_create functionality i

Re: PostGres 9.5 Upsert

On Sunday, January 10, 2016 at 9:09:37 AM UTC+1, Anssi Kääriäinen wrote: > > The save() operation matches the semantics of upsert exactly - maybe we > could use upsert there? > Not sure *.save()* would be a good candidate for that. In the best case, *.save()* should execute one INSERT or UPDAT

Re: deadlock risk from using cache a load time

On Wednesday, January 13, 2016 at 6:58:25 PM UTC+1, John Bazik wrote: > > I'm posting here because I think the problem is principally within django > - the apps I'm using are doing reasonable things. > I wouldn't call multisite/hacks.py reasonable :D That said, unpickling models requires apps

Re: 'noescape' filter for django template

And even then, |safe is exactly the same as |noescape On Monday, January 25, 2016 at 4:33:01 PM UTC+1, Tim Graham wrote: > > Is there some reason you cannot mark the string safe in Python code using > one of the following methods? I think that's where escaping logic belongs. > > > https://docs.dj

Re: deadlock risk from using cache a load time

On Tuesday, January 26, 2016 at 9:52:01 AM UTC+1, Aymeric Augustin wrote: > > However I think there's a bigger problem with this code. apps.populate() > should only be called by django.setup(). I think we should > revert 108b8bf852c76855ed98f5abe55db1da845598e7. > Revert yes, but a check like th

Re: Remove null assingment check for non-nullable fields?

On Wednesday, February 3, 2016 at 12:26:26 AM UTC+1, Tim Graham wrote: > > There's a proposal to remove this behavior: > > > >>> obj.fk = None > ValueError('Cannot assign None: "Obj.fk" does not allow null values.) > Yes please, if you do IntegerField(null=False) you can still do instance.xxx = N

Re: remove support for unsalted password hashers?

Hi, On Thursday, February 4, 2016 at 6:22:09 PM UTC+1, Raphaël Barrois wrote: > > Just as djangoproject.com might need to keep those old hashers around, > many projects will need it as well. > As such, providing the hashers in a dedicated "legacy" package might be > the solution for most projec

Re: Announcing Django-Zappa - Serverless Django on AWS Lambda + API Gateway

Hi Rich, to quote from your blog post: > the server is created *after* the HTTP request comes in through API > Gateway. It then turns the API Gateway request into normal Python WSGI, > processes the request, and returns it back through the API Gateway to the > client. > Doesn't that effective

Re: [Review Request] Added support for database delegated fields (like AutoField)

On Thursday, February 11, 2016 at 10:51:59 AM UTC+1, Anssi Kääriäinen wrote: > > Before doing any further work on this we should decide if the > Model.__init__() problem is bad enough to stop this cleanup, and if so, do > anybody have any ideas of how to avoid the problem? > I do not think Mod

Re: [Review Request] Added support for database delegated fields (like AutoField)

or model._meta.new_style_deferred and continue accordingly * Raise a warning if the __init__ is a custom one and new_style_deffered is not set… On Thursday, February 11, 2016 at 1:38:44 PM UTC+1, Florian Apolloner wrote: > > > > On Thursday, February 11, 2016 at 10:51:59 AM UTC+1, Anssi Kääriäinen &

Re: [Review Request] Added support for database delegated fields (like AutoField)

On Thursday, February 11, 2016 at 1:41:44 PM UTC+1, Florian Apolloner wrote: > > * Unless I miss something, YourModel.__init__ is Model.__init__ if the > user didn't change it -> pass is DEFERRED > Sadly this is not true, you can check if __init__ is in dict though… -

Re: [Discussion] Legacy documentation / Boken docs Django v1.2

On Thursday, February 18, 2016 at 4:24:09 PM UTC+1, Tim Graham wrote: > > I guess I'm not strongly opposed if someone wants to do that, but I don't > think I can justify spending time on the DSF's dime to help out users of > unsupported versions. > +1 -- You received this message because you

Re: remove old SVN branches from git repository?

On Wednesday, February 24, 2016 at 9:12:19 PM UTC+1, Shai Berger wrote: > > If they're a nuisance, I suggest that we clone the Django repo into > another > one under the django organization -- say, "django-historical-branches" -- > before removing them from the main repo. > I was about to s

Re: Improving django.setup() and app loading performance

On Friday, February 26, 2016 at 9:53:00 PM UTC+1, Rich Jones wrote: > > @Aymeric > > In my opinion, the first concrete step would be to measure how much time > is spent executing Django code rather than importing Python modules. > > Over 70% of the total request time is spent in django.setup() -

Re: Improving django.setup() and app loading performance

Hi Collin, On Friday, February 26, 2016 at 10:56:33 PM UTC+1, Collin Green wrote: > > Ugh. As a strong advocate of both django and zappa, I'd love it if we > could keep the conversation on target without degenerating into stack > attacks. If you don't want to weigh in, please feel no obligation

Re: Making max_length argument optional

-1 on adding an arbitrary default like 100/128… If people choose a CharField the should set max_length manually. In that sense I am for option 3. Cheers, Florian On Saturday, February 27, 2016 at 1:55:23 PM UTC+1, Wim Feijen wrote: > > Hi guys, > > I'd like to reach consensus about > https://c

Re: Making max_length argument optional

Hi Wim, On Saturday, February 27, 2016 at 2:33:27 PM UTC+1, Wim Feijen wrote: > > Can you please elaborate why the current situation is better? > I wouldn't say it is better, just equally good/bad ;) > In practice, most people add max_length=255 everytime by hand. I value > your opinion but

Re: Making max_length argument optional

Hi Shai, On Saturday, February 27, 2016 at 4:44:18 PM UTC+1, Shai Berger wrote: > > I think this is why we should be a little more cautious and go for 128 or > 100, > rather than "the current maximum all-backend-compatible value". > Which somewhat speaks for my point, cause we do not know if t

Re: Making max_length argument optional

On Sunday, February 28, 2016 at 9:57:27 AM UTC+1, Luke Plant wrote: > > We could also potentially add another sentinel like > DB_MAX_UNICODE_SAFE_LENGTH that works as you expect and is clearly > documented, for the sake of 3rd party apps, and comes with the caveat that > it produces different

Re: Making max_length argument optional

On Sunday, February 28, 2016 at 11:33:16 AM UTC+1, Loïc Bistuer wrote: > > I don't think this is a problem, we could validate that the backend > supports it during save then blow up if we detect it doesn't. I think we do > that for truncation on MySQL. If the model specifies something that the db

Re: Django startproject template enhancement proposal

On Saturday, March 12, 2016 at 5:29:55 PM UTC+1, is_null wrote: > > I know it's too opinionated to add that to django, but I'd like to > open a discussion here and perhaps there's something we might find > worth changing in django's default project template. > Imo it should stay as minimal as i

Re: Value of tightening URLValidator/EmailValidator regular expressions?

On Monday, March 14, 2016 at 8:08:09 PM UTC+1, Michael Manfre wrote: > > Simple is better. Anyone who needs/wants something more complex is not > prevented by Django from doing so. > +1 to that and what the rest said ;) > > Regards, > Michael Manfre > > On Mon, Mar 14, 2016 at 2:31 PM, Aymeri

Re: Translate permission Django

On Monday, March 14, 2016 at 9:24:30 PM UTC+1, Collin Anderson wrote: > > Maybe we could have __str__ run the text through _()? I don't do much > translating. > Wouldn't work since you'd still need the static strings for the po files somewhere. -- You received this message because you are s

Re: Value of tightening URLValidator/EmailValidator regular expressions?

On Tuesday, March 15, 2016 at 12:29:42 AM UTC+1, Josh Smeaton wrote: > > +1. I don't think we need strict email validation. "looks vaguely like an > email address" is enough for validation purposes in forms. Are there any > security concerns we need to be aware of though? > Absolutely, the cra

Re: Feedback on Django Channels

On Thursday, March 17, 2016 at 5:42:05 PM UTC+1, Jacob Kaplan-Moss wrote: > > Channels routes all WebSocket connections to a single set of consumers > (the `websocket.*` consumers). This means that if you want multiple > WebSocket URLs in a single app you need to manually parse the path. And, to

Re: Feedback on Django Channels

On Thursday, March 17, 2016 at 9:56:40 PM UTC+1, Jacob Kaplan-Moss wrote: > > I'd considered an API like this, and it's certainly clean and > straightforward. However, we've already got a URL routing library in > Django, so I think I'd like to try to find a way to re-use it for > websockets. I

Re: Status of DEP 0005: Improved middleware?

The current PR is here: https://github.com/django/django/pull/5949 -- Now that the general idea is clear, I think I will push it as branch to the main Django repo, so others can help working on it. There is still quite a bit to do, but the general functionality is working as intended. Cheers, F

Re: Make STATIC_URL context variable aware of backing storage with staticfiles

On Saturday, March 19, 2016 at 7:01:28 PM UTC+1, Daniel R wrote: > > But given the wide use of {{STATIC_URL}} this may be an easy and > worthwhile fix instead of asking users to change template references. > Wide? Not sure what your definition of wide is, but I suspect that the tag has way hig

Re: relative path in {% extends "...base.html" %} like relative import

On Sunday, March 20, 2016 at 5:57:41 PM UTC+1, Collin Anderson wrote: > > Hmm... I suppose the closest alternative we have would be to store the > base template name in a variable and pass it in from the view. > Either way, I fail to see how that feature would be really useful. -- You received

Re: relative path in {% extends "...base.html" %} like relative import

On Monday, March 21, 2016 at 8:25:46 AM UTC+1, Vitaly Bogomolov wrote: > > Here is code, that implement this feature for Django 1.4/1.9: > https://github.com/vb64/django.templates.relative.path >

Re: Using auth stuff without installing the auth app

Oh yes, this is a bug. We should ensure that RemoteUser backend is imported in the middleware itself or that backends.py does not trigger any model imports. Since the usage of any of the backends requires models, the import there seems fine -- I'd import RemoteUserBackend in RemoteUserMiddlewar

Re: [ GSOC 2016 ] Proposal for template profiling and optimization

Sorry, but this is no proposal -- this is a bad joke. You will need to put way more work into On Wednesday, March 23, 2016 at 7:05:13 PM UTC+1, girish ramnani wrote: > > > After reading through the db source code of django I realized the > complexity of adding a standard interface for NoSQL col

Re: [ GSOC 2016 ] Proposal for template profiling and optimization

Sorry, but this is no proposal -- this is a bad joke. You will need to put way more work into it… On Wednesday, March 23, 2016 at 7:05:13 PM UTC+1, girish ramnani wrote: > > > After reading through the db source code of django I realized the > complexity of adding a standard interface for NoSQL

Re: Using auth stuff without installing the auth app

On Wednesday, March 23, 2016 at 8:36:39 PM UTC+1, Matt wrote: > > I created https://code.djangoproject.com/ticket/26401 > > > > Since the usage of any of the ba

Re: Using auth stuff without installing the auth app

On Thursday, March 24, 2016 at 12:07:14 AM UTC+1, Matt wrote: > > > the ModelBackend uses the Permission model, so why would that ever work > without beeing in INSTALLED_APPS? > > ModelBackend.authenticate() doesn't use the permissions models. And that's > the method that gets used when authen

Re: Revisiting lazy middleware initialization

+1 -- Patches welcome :D On Friday, March 25, 2016 at 11:02:26 AM UTC+1, Aymeric Augustin wrote: > > On 24 Mar 2016, at 17:39, David Evans > > wrote: > > > Currently, middleware is initialized lazily on serving the first request, > rather than on application start. There may well have been good

Re: Value of tightening URLValidator/EmailValidator regular expressions?

Having a new field seems overkill to me -- a new validation routine which is less strict is something we should be able to do without backward compat considerations. The reasoning for this is easy: As long as it is not proven that the current regex covers only valid addresses a less strict valid

Re: Override the default form field for a model field

On Thursday, March 17, 2016 at 2:17:40 PM UTC+1, Tim Graham wrote: > > It seems useful, but I'm not sure if it increases the coupling between > model and forms in an undesirable way? > Yeah, I am also mostly worried about this. formfield for me is a quick shortcut, if you want to customize it,

Help needed & Status of DEP0005 (middleware handling)

Hi, so here is a short update for DEP0005: I've moved from a branch on my private repository to a branch named dep0005 on Django to make it easier for core developers to push there and to allow others to easily make pull requests against it. The code as is works fine, the remaining tasks are b

<    2   3   4   5   6   7   8   9   >