Re: Autocomplete fields and cleaned_data

2019-05-13 Thread Florian Apolloner
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

Re: Proposal to format Django using black

2019-05-02 Thread Florian Apolloner
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:

Re: Deferring "Sign the CLA"

2019-05-01 Thread Florian Apolloner
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

Re: Deferring "Sign the CLA"

2019-04-27 Thread Florian Apolloner
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: Proposal to format Django using black

2019-04-24 Thread Florian Apolloner
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 --

Re: Proposal to format Django using black

2019-04-16 Thread Florian Apolloner
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

Re: Proposal to format Django using black

2019-04-15 Thread Florian Apolloner
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,

Re: Proposal to format Django using black

2019-04-15 Thread Florian Apolloner
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

Re: Proposal to format Django using black

2019-04-14 Thread Florian Apolloner
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

Re: Proposal to format Django using black

2019-04-14 Thread Florian Apolloner
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

Re: Proposal to format Django using black

2019-04-14 Thread Florian Apolloner
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

Re: Proposal to format Django using black

2019-04-14 Thread Florian Apolloner
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

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

2019-04-14 Thread Florian Apolloner
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

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

2019-04-13 Thread Florian Apolloner
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: Proposal to format Django using black

2019-04-13 Thread Florian Apolloner
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

Re: Proposal to format Django using black

2019-04-13 Thread Florian Apolloner
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

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

2019-04-13 Thread Florian Apolloner
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

Re: Proposal to format Django using black

2019-04-13 Thread Florian Apolloner
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: 2020 Authentication Initiativ

2019-04-13 Thread Florian Apolloner
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: 2020 Authentication Initiativ

2019-04-13 Thread Florian Apolloner
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

Re: Converting serve static to class base views

2019-04-12 Thread Florian Apolloner
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

Re: 2020 Authentication Initiativ

2019-04-12 Thread Florian Apolloner
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: 2020 Authentication Initiativ

2019-04-10 Thread Florian Apolloner
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

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

2019-03-29 Thread Florian Apolloner
, 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 and t

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

2019-03-29 Thread Florian Apolloner
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 >

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

2019-03-19 Thread Florian Apolloner
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

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

2019-03-15 Thread Florian Apolloner
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

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

2019-03-15 Thread Florian Apolloner
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

Re: Official Django Docker Container Deprecated

2019-02-26 Thread Florian Apolloner
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

Re: Use CDN for djangoproject.com

2019-02-25 Thread Florian Apolloner
e >>>>>>>> artifacts from the djangoproject.com website. And we would like to >>>>>>>> ensure that the TLS termination happens by us and not some random >>>>>>>> service >>>>>>>> provider. After all, Django is used

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

2019-02-25 Thread Florian Apolloner
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

Re: Use CDN for djangoproject.com

2019-02-13 Thread Florian Apolloner
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

Re: Post mortem on today's packaging error.

2019-02-11 Thread Florian Apolloner
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

2019-02-11 Thread Florian Apolloner
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

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

2019-01-25 Thread Florian Apolloner
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

Re: revisiting the Python version support policy

2019-01-25 Thread Florian Apolloner
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

Re: Google Summer of Code 2019

2019-01-25 Thread Florian Apolloner
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

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

2019-01-01 Thread Florian Apolloner
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. >

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

2018-12-29 Thread Florian Apolloner
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

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

2018-12-29 Thread Florian Apolloner
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

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

2018-11-26 Thread Florian Apolloner
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 >

Re: Removing Oracle from Django core in 3.0

2018-11-26 Thread Florian Apolloner
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

2018-11-25 Thread Florian Apolloner
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

Re: Add Python 3.7 support for Django 1.11?

2018-11-18 Thread Florian Apolloner
On Sunday, November 18, 2018 at 5:21:14 AM UTC+1, Josh Smeaton wrote: > > Should this also be a policy change, or is it better to maintain a > position of "if it's relatively easy and unobtrusive"? > Imo absolutely the latter. Personally I am (sadly to late) not really happy with official

Re: Allow skipping CSRF check for Referer header

2018-11-10 Thread Florian Apolloner
think that feature flag rules it out for a long time? > > On Sat, 10 Nov 2018 at 09:52, Florian Apolloner > wrote: > >> Wouldn't one alternative be checking the Origin header? It appears though >> that all browsers support it with the sad exception that it is still behind

Re: Allow skipping CSRF check for Referer header

2018-11-10 Thread Florian Apolloner
Wouldn't one alternative be checking the Origin header? It appears though that all browsers support it with the sad exception that it is still behind a feature flag in Firefox. :/ (https://bugzilla.mozilla.org/show_bug.cgi?id=1424076) On Saturday, November 10, 2018 at 1:03:08 AM UTC+1, Adam

Re: CharField with Oracle Backend Null Behaviour

2018-11-08 Thread Florian Apolloner
Hi Vackar, Thank you, now we are getting somewhere! On Thursday, November 8, 2018 at 5:36:53 PM UTC+1, vaf...@exscientia.co.uk wrote: > > My main concern currently is that required fields are not enforced at the > db level, which makes using it with other clients difficult. I would much >

Re: CharField with Oracle Backend Null Behaviour

2018-11-08 Thread Florian Apolloner
On Thursday, November 8, 2018 at 3:52:01 PM UTC+1, vaf...@exscientia.co.uk wrote: > > - If null=False is specified, then add an explicit not null constraint at > the db level > As far as I understand Oracle makes no difference between null and an empty string. So if we were to add a not-null

Re: CharField with Oracle Backend Null Behaviour

2018-11-08 Thread Florian Apolloner
Oracle treats NULL and empty varchar2 the same; so null=True/False is simply not possible on Oracle for CharField. I am not sure what you are proposing here… -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)"

Re: Password reset token safety

2018-11-08 Thread Florian Apolloner
Hi, On Thursday, November 8, 2018 at 8:12:51 AM UTC+1, Alex Toussaint wrote: > > The attacker can have access to the password hash but no longer to the > last login. if that same attacker is exploiting a vulnerability that gets > patched just after (ex. Heartbleed) or has view on past data (ex.

Re: Password reset token safety

2018-11-07 Thread Florian Apolloner
Hi there, On Wednesday, November 7, 2018 at 10:22:06 PM UTC+1, Alex Toussaint wrote: > > I've been able, with a simple Python script, from having read-only access > to my Django webserver to a full read-write by crafting a reset token. > To be honest that script is weird at best; if you have

Re: backend specific tests

2018-11-07 Thread Florian Apolloner
On Wednesday, November 7, 2018 at 12:43:47 AM UTC+1, Dan Davis wrote: > > So, a developer using PostgreSQL doesn't need superuser privileges, but > you do to run Django's unit tests, because it will test these contributed > postgres operations. > I think one might get away with installing

Re: Model creation in autocommit mode.

2018-09-26 Thread Florian Apolloner
oject.com/ticket/21171 looks like it should help. > > On Wednesday, September 26, 2018 at 2:56:34 PM UTC-4, Florian Apolloner > wrote: >> >> Hi there, >> >> a fun issue came up on IRC today: Even when in autocommit mode, Django >> starts a transaction when do

Model creation in autocommit mode.

2018-09-26 Thread Florian Apolloner
Hi there, a fun issue came up on IRC today: Even when in autocommit mode, Django starts a transaction when doing Model.objects.create (https://github.com/django/django/blob/fb2964a4106b1282c4179b6fbbd0374f5be1ccac/django/db/models/base.py#L752). This makes some sense when there are parents to

Re: Deprecate PickleSerializer for session serialization?

2018-08-26 Thread Florian Apolloner
Yes, lets deprecate and remove it. No 3rd party package from Django itself, if someone wants it, they should write one. On Sunday, August 26, 2018 at 3:57:20 PM UTC+2, Adam Johnson wrote: > > +1 to deprecate. Maybe we deprecate and remove it, and some user makes a > third party package if they

Re: App static files (#29586)

2018-07-23 Thread Florian Apolloner
Hi Claude, On Monday, July 23, 2018 at 8:14:23 PM UTC+2, Claude Paroz wrote: > > Sure, the idea is to put a base structure in place to support such > functionalities at a later stage (in core or as 3rd party like > django-compressor). > I am just a little bit worried about adding this

Re: App static files (#29586)

2018-07-23 Thread Florian Apolloner
Hi Claude, a few things after a quick glance at it. Overall the feature seems rather simple and I do not see any reason why this would have to be in core from the start; ie it could easily evolve as a 3rd party app. I am not that much into frontend dev, but from my experience a few things

Re: The behavior of QueryDict.get(_key_, _default=None_)

2018-07-19 Thread Florian Apolloner
On Thursday, July 19, 2018 at 8:52:56 AM UTC+2, Carlton Gibson wrote: > > The usual case is to need a single value from the query string, so `[]` > and `get()` both return scalars. > `getList()` exists specifically for the case where you do want multiple > values. > I'd like to expand on

Re: Spaces between argument separator and argument in template filter generate error

2018-06-06 Thread Florian Apolloner
On Tuesday, June 5, 2018 at 4:30:03 AM UTC+2, oli...@kidsnote.com wrote: > > allowing spaces can be done by simply adding \s* after (arg_sep)s > \s is __not__ the regex for spaces -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions

Re: Simplify middlewares (again) and get rid of process_view

2018-05-16 Thread Florian Apolloner
Hi Carl, On Wednesday, May 16, 2018 at 5:58:02 AM UTC+2, Carl Meyer wrote: > > I'm not sure this part is feasible. It's an intentional part of > middleware design AFAIK (and useful) that middleware can modify > request.path and have this modification respected in view resolution. > my

Simplify middlewares (again) and get rid of process_view

2018-05-12 Thread Florian Apolloner
Hi there, After refactoring the middlewares to new-style middlewares as we have them now, I am left with two pain points: * atomic requests are still special cased and not in a middleware * process_view is as useless as always (it can neither alter nor convert args/kwargs or the view) To

Re: Any reason to not use SHA256 (or newer) for Signer / TimeStampSigner classess?

2018-05-10 Thread Florian Apolloner
On Thursday, May 10, 2018 at 1:31:43 AM UTC+2, Cristiano Coelho wrote: > > Right, that backwards compatibility issue seems quite difficult to solve, > although if the worst thing to happen is that all users are logged out, it > shouldn't be that bad. Will read the ticket in detail. > That is

Re: Thoughts on diff-based migrations with django?

2018-05-02 Thread Florian Apolloner
Just for one migration; but there is the sqlmigrate management command which you can use as building base. Cheers, Florian On Wednesday, May 2, 2018 at 7:07:27 AM UTC+2, djrobstep wrote: > > Bump! Is there a documented way to generate the from-scratch creation SQL > for the currently defined

Re: ExceptionMiddleware still necessary in documentation?

2018-04-25 Thread Florian Apolloner
It got removed in https://github.com/django/django/commit/7d1b69dbe7f72ac04d2513f0468fe2146231b286 -- as such it can also be removed from the documentation. On Wednesday, April 25, 2018 at 9:34:07 PM UTC+2, Shiyang Wang wrote: > > Hello! > > Following up from this issue:

Re: Fabric examples in documentation

2018-04-25 Thread Florian Apolloner
I'd just drop the paragraph On Wednesday, April 25, 2018 at 7:42:45 PM UTC+2, Tim Graham wrote: > > From https://code.djangoproject.com/ticket/29360: > > "The ​Serving the site and your static files from the same server >

Re: Shouldn't manage.py call python3 instead of python?

2018-04-10 Thread Florian Apolloner
On Tuesday, April 10, 2018 at 1:28:33 PM UTC+2, Tim Allen wrote: > > Since `django-admin startproject my_project` is created on the fly from > templates, couldn't we dynamically create the `manage.py` executable based > on some system introspection and an agreed upon priority > Wouldn't that

Re: PEP 484 type hinting in Django

2018-04-06 Thread Florian Apolloner
of type hinting: >> https://groups.google.com/d/topic/django-developers/z_P1TvJ6QG8/discussion >> https://groups.google.com/d/topic/django-developers/xOTmq93YZuQ/discussion >> >> On Wednesday, August 17, 2016 at 5:30:56 AM UTC-4, Florian Apolloner >> wrote: >>

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Florian Apolloner
On Thursday, February 22, 2018 at 9:52:04 PM UTC+1, Josh Smeaton wrote: > > Or, since this isn't a template tag (facepalm) > Which raises a perfectly valid point: If we were to change this, we will also need to come up with a new name for the "|safe"-filter. -- You received this message

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Florian Apolloner
Yeah, I am also worried about the churn for no gain in my eyes. If users overuse mark_safe, they will overuse dangerously_trust_html too… On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote: > > I agree that the names are misleading and we should probably provide > better

Re: Allow namespaced reusable app urls as ROOT_URLCONF

2018-02-16 Thread Florian Apolloner
On Friday, February 16, 2018 at 3:08:33 PM UTC+1, Vlastimil Zíma wrote: > > but to respect namespace if a ROOT_URLCONF has one. > I understood it like that; but as I said I didn't see many valid usecases. Your point about testing though is a good one! -- You received this message because

Re: Allow namespaced reusable app urls as ROOT_URLCONF

2018-02-15 Thread Florian Apolloner
Hi, On Thursday, February 15, 2018 at 2:40:07 PM UTC+1, Vlastimil Zíma wrote: > Is there a reason not to use namespace from root urlconf? Can we change > that, i.e. make root resolver to load the app_name of the root urls? Did I > missed something else? > I don't think there is any reason to

Re: Ticket #29015

2018-01-21 Thread Florian Apolloner
You could use ``` if settings_dict.get('NAME') and len(settings_dict['NAME']) ``` if you wanted to prevent a KeyError too. On Sunday, January 21, 2018 at 8:56:40 AM UTC+1, askpr...@gmail.com wrote: > > Hello ! > > I have updated the PR as per Adam's review. However, I have not changed > L155 in

Re: Default Authorization BackEnd Denying Permissions if Object Provided

2018-01-18 Thread Florian Apolloner
On Thursday, January 18, 2018 at 2:55:27 AM UTC+1, Mehmet Dogan wrote: > > If that is the way forward, I will volunteer for the code. But, as you > also point out, there needs to be a *path* out. That I don't know :) > Personally I think it is (though I haven't had hours to think about it).

Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

2018-01-17 Thread Florian Apolloner
On Wednesday, January 17, 2018 at 9:04:30 PM UTC+1, Mehmet Dogan wrote: > > Although I found it very interesting at first, this looks dangerous since > it changes how the API work for all apps installed. Example, guardian makes > calls to user.has_perm(perm) in several places to check model

Re: Default Authorization BackEnd Denying Permissions if Object Provided

2018-01-17 Thread Florian Apolloner
On Wednesday, January 17, 2018 at 7:58:17 PM UTC+1, Carlton Gibson wrote: > > Given your comment, would it be along the lines of "Close as "Won't Fix", > perhaps with a review of the documentation", to point users to subclassing > ModelBackend if they need the alternate behaviour? > My comment

Re: Default Authorization BackEnd Denying Permissions if Object Provided

2018-01-17 Thread Florian Apolloner
On Wednesday, January 17, 2018 at 5:48:03 PM UTC+1, Mehmet Dogan wrote: > > Florian, > > Can you clarify this part, I am not sure what you meant: > class MyBackend(ModelBackend): def has_perm(…, obj=None,…): if obj: obj = None return super().has_perm(…) something along the lines

Re: Default Authorization BackEnd Denying Permissions if Object Provided

2018-01-17 Thread Florian Apolloner
On Wednesday, January 17, 2018 at 11:45:05 AM UTC+1, Carlton Gibson wrote: > > The objection is to this kind of check: > > if user.has_perm('foo.change_bar', obj=bar) or > user.has_perm('foo.change_bar'): > ... > FWIW I would never write code like this.

Re: Removing ORM's union restrictions

2017-12-13 Thread Florian Apolloner
On Monday, December 11, 2017 at 11:19:12 PM UTC+1, Thijs van Dien wrote: > > In case there's an ORDER BY, I suppose you would need a wrapper. It's what > got me here in the first place; I was surprised how much difficulty this > user was having when attempting something rather basic: >

Re: ModelForm unique validation is not done right IMHO.

2017-10-09 Thread Florian Apolloner
Hi, On Monday, October 9, 2017 at 8:52:53 AM UTC+2, Todor Velichkov wrote: > > Settings values programmatically is a cumulative operation most of the > time, however when its not and things depend on each other (like your > example), then even the docs suggests than one can use the form.clean

Re: ModelForm unique validation is not done right IMHO.

2017-10-08 Thread Florian Apolloner
On Saturday, October 7, 2017 at 5:07:31 PM UTC+2, Todor Velichkov wrote: > > I believe this could save a lot of headache to people. If there is no > guarantee that an instance cannot be saved after the form has been > validated, then do not give me an option to shoot myself into the foot. >

Re: ModelForm unique validation is not done right IMHO.

2017-10-07 Thread Florian Apolloner
I think the current behaviour is correct. Django shouldn't make any assumptions about fields not in the form since it doesn't know what will happen… In that sense I disagree with the statement: > From my point of view when I define a ModelForm I imagine that I have to only explain what the

Re: about ticket 28588- has_perm hide non-existent permissions

2017-10-02 Thread Florian Apolloner
Hi, On Monday, October 2, 2017 at 2:24:31 PM UTC+2, moshe nahmias wrote: > > If yes I think I have a good solution, I will return on the check if perm > in Permission.all() > Where exactly do you propose to do that? Here:

Re: about ticket 28588- has_perm hide non-existent permissions

2017-09-30 Thread Florian Apolloner
Hi, On Friday, September 29, 2017 at 7:00:41 PM UTC+2, moshe nahmias wrote: > > 3. Return False if the permission doesn't exist means that we go through > the same path as a regular user, since (at least on > auth.backends.ModelBackend) we check already if the user is superuser and > if so we

Re: Discuss: Add a new setting for https schema

2017-08-20 Thread Florian Apolloner
I think in those cases a small middleware would be prefered opposed to a new setting (and therefore nothing which needs to be in core). That said: how is the "cloud" telling you if the request is https or not? Cheers, Florian On Sunday, August 20, 2017 at 7:03:08 PM UTC+2, wangwenpei wrote: >

Re: Django 2.0 Python version support (Python 3.6+ only?)

2017-08-08 Thread Florian Apolloner
Hi Tim, I've just looked through the list of systems in use here: * Debian stable: Python 3.5.3 * Ubuntu 16.04 (yes, LTS): 3.5.2 * CentOS 6/7 (and therefore also RHEL): 3.3-3.5 via SCL, 3.3-3.6 via IUS So all in all dropping 3.4 would be doable. I'd still strongly object to dropping 3.5.

Re: Improving Windows users experience at the command line

2017-07-11 Thread Florian Apolloner
Hi Ramiro, On Tuesday, July 11, 2017 at 10:55:38 PM UTC+2, Ramiro Morales wrote: > > - I run django-admin.py startproject and I get an error message stating > django-admin.py isn't a known command > FWIW django-admin.py shouldn't be used any more nowadays -- my latest changes should install

Re: django.core.signing and safe characters

2017-06-21 Thread Florian Apolloner
Hi Ole, On Wednesday, June 21, 2017 at 12:42:39 PM UTC+2, Ole Laursen wrote: > > I'm sorry if I gave the impression that I'm trying to nitpick > adherence to a standard. > You absolutely did not, I guess my mail was tenser than it was intended to be. > What I'm addressing here is

Re: django.core.signing and safe characters

2017-06-20 Thread Florian Apolloner
Hi, On Tuesday, June 20, 2017 at 12:18:21 PM UTC+2, Ole Laursen wrote: > > Yet, : is specifically mentioned as a reserved character: > It depends on the context. The assumption here is that the encoded data is always used as part of the path/querystring, for which rfc1738 says: Within the

Re: Vendoring Select2

2017-06-06 Thread Florian Apolloner
On Tuesday, June 6, 2017 at 11:54:16 AM UTC+2, Johannes Hoppe wrote: > > I think we made some good progress in the regarding this issue. The > inclusion of select2 is at a stage where I wouldn't want to jump to a > different library. Especially considering that now one acted at this ticket >

Re: Tabs in Django Admin forms?

2017-05-30 Thread Florian Apolloner
> to group form fields in tabs (as django-crispy-form does)?. For those who do not know django-crispy-form, how does that look like? Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To

Re: Integrate dj-database-url into Django

2017-05-25 Thread Florian Apolloner
On Thursday, May 25, 2017 at 9:46:56 AM UTC+2, Aymeric Augustin wrote: > > I'm wary of possible security ramifications: if we do this, changing a > configuration value will import an arbitrary module, which could make it > easier to run arbitrary code in some scenarios. I don't have a clear

Re: migration lock file implementation

2017-05-24 Thread Florian Apolloner
On Wednesday, May 24, 2017 at 9:42:20 PM UTC+2, Andrew Godwin wrote: > > I am personally unsure about this - it's extra overhead for smaller Django > sites, and something that larger teams could easily adopt themselves. > Yeah, I do not see an immediate need for this either. -- You received

Re: Integrate dj-database-url into Django

2017-05-24 Thread Florian Apolloner
Hi Kenneth, I think there are a few things to consider before we can merge/reuse dj-database-url. * How are third party backends going to fit into this scheme? * What about other options like CACHES which very much suffers from the same problem. Cheers, Florian -- You received this

Re: Cython usage within Django

2017-05-22 Thread Florian Apolloner
On Monday, May 22, 2017 at 1:30:20 AM UTC+2, Tom Forbes wrote: > > As I understand it the Django project itself would not distribute > pre-compiled wheels, the setup.py Cython 'stuff' would handle this (and > fail gracefully if anything goes wrong, like no C compiler being > available). >

Re: Review of DEP 201 - simplified routing syntax

2017-05-12 Thread Florian Apolloner
On Friday, May 12, 2017 at 12:33:28 PM UTC+2, Aymeric Augustin wrote: > > Django's URL resolver matches URLs as str (Unicode strings), not bytes, > after percent and UTF-8 decoding. As a consequence \d matches any > character in Unicode character category Nd >

Re: Problems around SchemaEditor._alter_field

2017-05-11 Thread Florian Apolloner
I've pushed an initial PR [1], sadly I had to change one of the signatures. But I think this is an okayish change for 2.0 given that it is internal API anyways. Cheers, Florian https://github.com/django/django/pull/8487/ On Tuesday, May 9, 2017 at 3:24:46 PM UTC+2, Florian Apolloner wrote

Problems around SchemaEditor._alter_field

2017-05-09 Thread Florian Apolloner
I am currently trying to (again?) write a database backend for Informix. So far so good, but I am running into one major issue: All of Django's other databases support changing null/default properties via "ALTER TABLE ALTER col DROP NULL/DEFAULT" or what not. In Informix I can only use "ALTER

Re: Proposal: provide postgresql powered full-text search in djangoproject.com

2017-05-07 Thread Florian Apolloner
On Sunday, May 7, 2017 at 12:45:27 PM UTC+2, Adam Johnson wrote: > > I guess we'd also have the benefit of not having to keep elasticsearch > running. > On the contrary, putting it into postgres means we have to care about it. Putting it into Elasticsearch means we can let our hoster take care

Re: Proposal: provide postgresql powered full-text search in djangoproject.com

2017-05-07 Thread Florian Apolloner
What would be the benefit of using django.contrib.postgresql aside from much work? On Sunday, May 7, 2017 at 12:50:02 AM UTC+2, Paolo Melchiorre wrote: > > Hello, > > in the djangoproject.com the search is powered by elasticsearch. > > Since the site uses postgresql as database backend I want

Re: Django 1.11 released

2017-04-05 Thread Florian Apolloner
Not on purpose no -- if it doesn't work with 4.1 that is a bug On Wednesday, April 5, 2017 at 11:07:13 AM UTC+2, jorr...@gmail.com wrote: > > Is the required version of Pillow pinned at 4.0.0? I upgraded to Django > 1.11 and from Pillow 4.0.0 to 4.1.0 but now Django doesn't start because it >

  1   2   3   4   5   6   7   8   >