On Monday, May 13, 2019 at 8:25:56 PM UTC+2, Melvyn Sopacua | 3YOURMIND
> 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
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:
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
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
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
It does, "# fmt: off" and "# fmt: on" can be used
this would only affect Django 3.0 which supports only python3.6 -- as such
you couldn't even run Django on those systems anyways.
On Tuesday, April 16, 2019 at 10:12:20 AM UTC+2, Emil Madsen wrote:
> I'm not sure if it's relevant for the discussion, but
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
On Monday, April 15,
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.
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 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
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
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
This is imo not something that scales well. Also it is not something I want
to pay our fellows for, I
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
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
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
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.
qs.order_by().first() should do what you want and is not worth adding .one()
On Saturday, April 13, 2019 at 5:48:29 PM UTC+2, alTus wrote:
> Please consider if that proposal can be useful not only for me :)
> `QuerySet.first` is quite useful shortcut but its
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
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.
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
I do not think that is the hardest possible way and as
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
On Thursday, April 11, 2019 at 11:05:36 PM
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).
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
, 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
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
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
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
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
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
>>>>>>>> artifacts from the djangoproject.com website. And we would like to
>>>>>>>> ensure that the TLS termination happens by us and not some random
>>>>>>>> provider. After all, Django is used
it is not (just) about links, it is mainly about stylesheets/js. But we can
set a header on that view:
This should work for every browser != IE/Edge.
On Friday, February 22, 2019 at 9:35:53
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
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
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
On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
> Is it possible to utilize a CDN service for
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
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
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
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.
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
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
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
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
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
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
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
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. :/
On Saturday, November 10, 2018 at 1:03:08 AM UTC+1, Adam
Thank you, now we are getting somewhere!
On Thursday, November 8, 2018 at 5:36:53 PM UTC+1, vaf...@exscientia.co.uk
> 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
On Thursday, November 8, 2018 at 3:52:01 PM UTC+1, vaf...@exscientia.co.uk
> - 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
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
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)"
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.
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
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
oject.com/ticket/21171 looks like it should help.
> On Wednesday, September 26, 2018 at 2:56:34 PM UTC-4, Florian Apolloner
>> Hi there,
>> a fun issue came up on IRC today: Even when in autocommit mode, Django
>> starts a transaction when do
a fun issue came up on IRC today: Even when in autocommit mode, Django
starts a transaction when doing Model.objects.create
This makes some sense when there are parents to
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
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
I am just a little bit worried about adding this
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
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
I'd like to expand on
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
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.
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)
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.
Just for one migration; but there is the sqlmigrate management command
which you can use as building base.
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
It got removed in
-- 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:
> Following up from this issue:
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
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
of type hinting:
>> On Wednesday, August 17, 2016 at 5:30:56 AM UTC-4, 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
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
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
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
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
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).
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
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?
On Wednesday, January 17, 2018 at 5:48:03 PM UTC+1, Mehmet Dogan wrote:
> Can you clarify this part, I am not sure what you meant:
def has_perm(…, obj=None,…):
if obj: obj = None
something along the lines
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
FWIW I would never write code like this.
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:
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
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.
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
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:
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
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?
On Sunday, August 20, 2017 at 7:03:08 PM UTC+2, wangwenpei wrote:
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
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
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
> What I'm addressing here is
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:
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
> 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?
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
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
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.
I think there are a few things to consider before we can merge/reuse
* How are third party backends going to fit into this scheme?
* What about other options like CACHES which very much suffers from the
You received this
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
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
I've pushed an initial PR , 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
On Tuesday, May 9, 2017 at 3:24:46 PM UTC+2, Florian Apolloner wrote
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
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
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
What would be the benefit of using django.contrib.postgresql aside from
On Sunday, May 7, 2017 at 12:50:02 AM UTC+2, Paolo Melchiorre wrote:
> in the djangoproject.com the search is powered by elasticsearch.
> Since the site uses postgresql as database backend I want
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 - 100 of 707 matches
Mail list logo