It's worth noting that during that two-week time period the core team has
been a bit preoccupied with doing a security release and followup bugfix
release :)
If no-one else has looked at and commented on those two DEPs within the
next day or two, I will have time to do so, and will do so (and feel
On Tue, May 27, 2014 at 12:07 PM, Meira wrote:
> It seems to be, there are enough reasonable people leaving comments like
> this one: https://github.com/django/django/pull/2720#issuecomment-44296843
>
We'll just get the databases to change their terminology before we change
ours!
Of course, the
We're closing in on the final Django 1.7 release, so it's release-candidate
time!
Details are up on the Django project blog:
https://www.djangoproject.com/weblog/2014/jun/26/17rc1/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubs
Check out the weblog for details (including information on a change to the
keys used to sign Django releases):
https://www.djangoproject.com/weblog/2014/jul/27/17rc2/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this
Speaking for myself, I am still willing to hand over the reins of
django-registration to someone who's genuinely motivated to try to solve
the issues surrounding things like custom User support, etc., though I
still do believe that's just a bridge too far for what was meant to be a
simple app.
I'v
I like the idea -- if nothing else, it would provide an easy way to have a
test suite discover N+1 problems, especially in templates.
Not sure about the feasibility, though; would you be willing to work up a
rough implementation of it?
--
You received this message because you are subscribed to t
Two things:
1. This is django-developers, the list for discussing the development of
Django itself. For questions about using Django or Django-based
applications, please use the django-users mailing list.
2. You've just shared your SECRET_KEY setting publicly with thousands of
people who received
Today we've issued releases to address four security issues reported to us.
Full disclosure is on the djangoproject.com weblog:
https://www.djangoproject.com/weblog/2014/aug/20/security/
All users are encouraged to upgrade.
Additionally, for anyone who missed it, last week we published an adviso
Django 1.7 is now available:
https://www.djangoproject.com/weblog/2014/sep/02/release-17-final/
Alongside this are bugfix releases for 1.4, 1.5 and 1.6. The bugfix 1.5
release is the final releae in the 1.5 series, as Django 1.5 has now
reached end-of-life.
--
You received this message because
I have been involved in building and participating in and running
technically-oriented groups for fifteen years. I've seen a lot of stuff.
The most common problem pattern I have seen is the "I'm not touching you"
game. To understand what this means, imagine parents driving a car, with
two children
On Tue, Sep 9, 2014 at 6:25 PM, Benjamin Scherrey
wrote:
> I really appreciate you for being the first person to directly respond
> to this most critical issue in this debate. You are correct, this incident
> is quite central to my point and concern. However, I have again reviewed
> the group
The first bugfix release in the 1.7 series is out, along with bugfix
releases for the supported 1.4 and 1.6 release series, and what will
hopefully be the final release of the 1.5 series, which is now past
end-of-life.
Full details are available on the Django project weblog:
https://www.djangopro
On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney wrote:
>
> Yeah, I expected DRF had this "solved" already. From my own
> experimentation, mapping `cgi.parse_header` over the the "Accept" header
> value, split by comma, gets a usable result; then sort that list by 'q'
> (defaulting to 1.0) and you
Since this discussion seems to be exclusively about how to use Django,
please take it to the django-users mailing list; the django-developers list
is not an appropriate place for this topic.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contrib
For several years, there have been efforts underway to change the way
the Django open-source software project is run. This eventually
produced a concrete proposal, which then went through discussion,
revision, and voting by the Django core team, Django Technical Board,
and Django Software Foundatio
A quick refresher on this since DEP 10 governance is still quite new:
Mergers have no special decision-making privileges -- being a Merger,
while important for the project, is not equivalent to the former
"committer"/"core" status, and is not used as an honor or as a reward
for past service or con
So I guess it's worth walking through how to do this.
The first step would be a member of the Technical Board deciding
Mariusz' suggestion is a good one, and nominating Claude to be a
Merger, putting the question to the full Technical Board for voting:
"Shall Claude be appointed a Merger?"
The Te
On Sat, Mar 14, 2020 at 5:00 AM Markus Holtermann
wrote:
> Claude has been contributing to Django for almost a decade. His roles in i18n
> related matters has been a constant help to the project. Providing Claude
> with commit access to github.com/django/django and giving him the MERGER role
>
I'm also in the "I don't think this should be allowed" camp. People
who really need it can set up their own validator easily enough, and I
worry about the security implications of supporting non-standard
behavior in something as crucial as hostname validation -- Django's
been bitten by that sort of
The end of support simply means there will be no further releases, and
any showstopping bugs reported will not be fixed. It doesn't mean
Django itself will stop working. Also, the decision is in the hands of
the Technical Board, not the Django Fellows, so the correct process
would be to request tha
The purpose of OrderedDict is that it's a dictionary type where
iteration yields keys in the order they were inserted. In older
versions of Python, this was not guaranteed, so a special ordered
version was needed.
Django 3.0 supports only Python 3.6 and newer; as of Python 3.6,
iterating a normal
On Fri, Apr 10, 2020 at 10:40 PM אורי wrote:
> In this form I need to insert fields in the beginning of the form, and
> therefore I call move_to_end. It worked with Django 2.2 but not with 3.0
> because this method is not defined in a dict. So I think if you revert to
> using OrderedDict, u
Last month the process of adopting DEP 10 -- new governance for the
Django project -- was completed:
https://www.djangoproject.com/weblog/2020/mar/12/governance/
As a result, we are now in the implementation stage. Although there
will almost certainly be other items that pop up on the to-do list,
I understand that this will probably get shouted down due to the
popularity of JWTs, but: I don't think Django should include any type
of JWT support in the core framework.
JWTs are an absolute security nightmare. Some of the Django security
team have heard me rant on this topic already, but: ther
On Sun, Apr 26, 2020 at 8:46 AM Adam Johnson wrote:
>
> James, I too would like to know your criticisms! I've always understood that
> they aren't much different to signed cookies, but I haven't looked too deeply
> at them.
Well, people asked. So.
The short summary is: JWT is over-complex, put
On Tue, May 5, 2020 at 8:42 AM Collin Anderson wrote:
> Is this really worth it? It's only a few lines of code to keep backward
> compatibility, and it seems to me it would take almost no work to maintain
> that compatibility shim compared to the countless programmer hours needed to
> upgrade t
On Tue, May 5, 2020 at 9:45 AM אורי wrote:
> My project contains about 100 calls to url() with regex. Can you explain to
> me what has been changed and why, and how should I change my code to stop
> using url()? And where is it documented? I checked the documentation and I
> didn't find an
On Tue, May 5, 2020 at 1:05 PM Collin Anderson
wrote:If it were 10 years from the proposal being accepted (2017 to 2027),
I think that would be fine for removal then. It allows for a more natural
upgrade as path() becomes more and more common. I don't see keeping url()
around as slowing down Djang
On Tue, May 5, 2020 at 2:04 PM Shai Berger wrote:
> Why? Why is 10 years ok where 7 are not? James' points on this are spot
> on.
>
> Be that as it may, I can see sense in the request for a longer
> warned-deprecation period, which the current path does not offer. I
> would be ok with introducing
On Tue, May 5, 2020 at 2:24 PM Collin Anderson wrote:
> If exception/special treadment is an issue, then I'd suggest making this an
> official policy change going forward. I would be much happier if all of the
> examples you gave were still around with warnings. All of those upgrades were
> ann
I've been working on documentation updates to get the DEP 10
governance listed in the docs, but it's unlikely I'll be able to PR it
until this weekend. How do people feel about that also being included
in 3.1? It's not exactly a feature change, and it arguably corrects a
bug in that the docs as the
The use case for namespace packages is the ability to fragment
portions of a single package across multiple disparate locations on
the filesystem. And, potentially, to install or selectively
enable/disable access to only certain sub-portions of the package by
choosing which parts are present or by
While I think Adam's right that adding one or two new settings
wouldn't be a problem, I do worry about the ongoing proliferation, and
it's a thing that I keep wanting to try to find the time to work on
but never actually succeed at.
Separate from the suggestion of a generic way to add headers on e
On Tue, Oct 6, 2020 at 9:07 AM Florian Apolloner wrote:
> So, I have been digging a little bit more and it seems there was a conscious
> decision to not include an entropy check or character classes:
> https://groups.google.com/g/django-developers/c/9GBhgGXmEKs/m/toKKgGhaqewJ --
> But I have to
Taking this as a question posed under the DEP 10 voting process of whether
or not to accept DEP 11:
I vote +1.
I think the basic idea is good; there are a couple things worth clarifying,
mostly in terms of oversight, but that can be addressed in later edits.
And by "oversight" I mean a clear sta
On Tue, Dec 15, 2020 at 6:07 PM Diptesh Choudhuri
wrote:
> Instead of removing the default test runner altogether, I can work on adding
> a TESTING_BACKEND variable in settings.py with possible values being
> 'django.testing.backends.pytest' (default) or
> 'django.testing.backends.DefaultRunner
On Wed, Dec 16, 2020 at 1:39 PM Adam Johnson wrote:
>> manage.py migrate app 0050_migration_from_master will unapply too much
>> (specifically, all the subsequent migrations from master)
>
>
> I don't follow you. This is exactly the thing I do, migrating back to the
> last common migration.
I t
I'm going to be the contrarian here and at least ask whether the right
answer is "don't do any of these options".
To see why, consider a hypothetical world where we do one of the above
options, and a site sets whatever config is necessary to disable
APPEND_SLASH behavior in the admin.
The very ne
On Sun, Feb 28, 2021 at 2:39 AM Tom Forbes wrote:
>
> Thank you for the clarification! I think the biggest argument for this change
> is the fact that uppercasing Unicode can cause incorrect results to be
> returned.
>
> Given that we now have much better support for custom index types, perhaps
Any time this happens, just notify the DSF Board; they're the ones
with the legal standing to enforce the trademark.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop r
It's not really a discussion of whether "we" (this list) want
something removed; how to enforce Django's trademark is purely the
domain of the DSF. The DSF also has the ability to wave its ownership
of the trademark around and hire lawyers in cases where people are
reluctant to take something down,
There are ways to check "close enough" equality for floats. There's
even the math.isclose() function which is arbitrarily tune-able:
https://docs.python.org/3/library/math.html#math.isclose
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contrib
Currently, the ability to set 'formfield_callback' on a ModelForm is
undocumented, and a ticket to document it[1] was closed wontfix by Tim
with the comment:
> The attribute is described as an "internal implementation detail" in #12915
> and the possibility of moving it to Meta is discussed. Ther
On Fri, Jun 4, 2021 at 11:54 PM Carlton Gibson wrote:
> I'm sympathetic to the suggestion here, but wary of expanding the Forms API,
> which already has a number of different ways of holding it.
>
> > ...to impose uniform custom widget attributes and error messages across a
> > bunch of ModelFor
On Sat, Feb 5, 2022 at 7:39 AM Christian González
wrote:
> Disclaimer: Yes, I know that I am somehow polluting the AppConfig namespace
> with attrs and methods that could clash with the ones you will add in far
> future... Pretix does that too, and honestly, there is hardly a good method,
> exc
To be honest, I'm curious why the SQLAlchemy approach isn't being discussed
more here. Implementing a calculated-field property decorator, and
supplying both the SQL side (via a method which returns a Q object, most
likely) and the Python side wouldn't be too difficult to implement, and
avoids the
I can think of several cases where I'd want a custom field to be able to
add an index, and contribute_to_class() is, as you say, the natural place
to do it -- it's the hook for everything else fields want to add as part of
their setup.
So I'd be +1 on making sure it's possible to add indexes throu
One approach you might try is on every test run, randomly select some lines
from the list of common passwords and verify they fail the validator. That
way we know it's not just testing a single, fixed, contrived case.
--
You received this message because you are subscribed to the Google Groups
"
I've written this up in pseudo-DEP format partly for ease of
organization, and partly because I'm unsure whether it would require a
DEP. Right now I'm just throwing it out here as a proposal, and
offering to work on implementing it; if you have questions, concerns,
or suggestions for things to add
If anyone feels competent to review, there's a PR open now for the first
part of this, adding Referrer-Policy support:
https://github.com/django/django/pull/9953
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" gr
On Thu, May 31, 2018 at 1:39 AM, wrote:
> Are there any reasons that not allow spaces between separator and arg?
>
Every optional variant of template syntax is a potential source of bugs or
compatibility issues for the future. And a potential source of confusion
when someone is trying to learn b
On Fri, Aug 17, 2018 at 1:50 AM, Nils Fredrik Gjerull
wrote:
> I still would like a technical answer to why not support both standards?
> And again XHTML5 is HTML5 with valid XML syntax. So valid XHTML5 is
> valid HTML5, so there is no problem for a framework to provide HTML5 it
> should just be
On Fri, Aug 17, 2018 at 3:41 AM, Nils Fredrik Gjerull
wrote:
>
> I am talking about being able to serve pages as application/xhtml+xml,
> this is defined by browser support as is the SGML version of HTML5. I
> hardly think XML version of HML5 is more ill-defined than the SGML
> version. I am not t
I'd be -1 on anything that encourages people to use ModelForm with all
fields included by default; that's asking for mass-assignment security
holes.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubs
There's been some discussion recently amongst the Django security team
regarding the way we handle advance notifications of security isues,
and whether we ought to change that. But since the security team is a
pretty small group, we'd like to take the discussion public and get
broader input before
The only use case for pickle that I'm aware of is "I need a way to add a
security hole to my site". So let's just get rid of it.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this grou
This type of enforced "complexity" does not increase security, and relevant
standards groups now recommend not trying to enforce these rules.
Quoting US NIST 800-63B, Appendix A:
> As noted above, composition rules are commonly used in an attempt to
increase the difficulty of guessing user-chosen
I'm agreeing with the other replies saying that if this is really needed,
it can be done as a third-party module.
As much as possible, I want to have Django avoid promoting outdated
security policies (and the fact that many places still use them doesn't
mean they're current; it means they haven't
cit policy, e.g. if they're on an unsupported version two years
> in a row, with no migration progress, they get removed?
>
> (There are also a couple misspellings - notifiations and regaring)
>
> On Sun, 26 Aug 2018 at 12:37, James Bennett wrote:
>
>> There'
On Wed, Oct 3, 2018 at 2:18 AM Markus Holtermann
wrote:
> Can: yes. Should: no.
Yeah, the idea's been proposed a couple times, and my stance on it is that
I'd quit not just the security team, but everything Django-related, if we
did that. Pay-to-play for security is not acceptable, period.
--
I still don't understand the problem this is solving; is typing "pk=" (or
"id=") that much of a burden? Or that frequently left out by accident?
As it stands, I agree with Adam that this adds implementation complexity
(including potential future implementation complexity, as Ivan noted) and
prolif
SECRET_KEY is the closest thing Django has to a “root password”. That’s why
we emphasize keeping it secret — someone who knows your SECRET_KEY can
effectively do anything to your site anyway. For example, they could
produce valid session cookies for any user, and then just hop in the admin
interfac
FWIW I'm pretty strongly -1 on this feature because Python's enums don't
behave the way people want them to for many use cases.
The basic problem is that, to take the example in the ticket, if I were to
issue a request like "/students/?year=FR", and the view were to read that
"year" param and try
Shai, your rebuttal still misses an important use case, which is
containment.
To continue with your example of a 'SchoolYear(str, Enum)', the following
will both be False:
'FR' in SchoolYear
'FR' in SchoolYear.__members__
The first of those is also becoming illegal soon -- attempting an 'in'
com
I worry about the precedent we'd set if we made an exception for Debian,
because the next question would be "OK, can we have an exception for Red
Hat, too?" Keep in mind Red Hat currently sells up to fourteen years of
support for their RHEL platform.
So I think it's best to recognize that:
People
On Fri, Jan 25, 2019 at 9:39 AM Linus Lewandowski <
linus.lewandow...@netguru.co> wrote:
> True, probably a way to access headers without marking them as used would
> be required - maybe something like request.headers.get(XYZ,
> vary_response=False).
>
> However, right now people are commonly forg
On Tue, Feb 19, 2019 at 4:44 AM 'Lance Ellinghaus' via Django developers
(Contributions to Django itself) wrote:
> Should I consider his statements to be the final statement from the Django
> core developers?
>
> You should take it as someone giving their opinion on the users list.
This is the c
On Sat, Feb 23, 2019 at 9:48 PM Philip James
wrote:
> Hi! I think I'm misunderstanding what you're asking for. I've looked at
> every doc I can find on annotations to refresh my memory, and it looks like
> annotations only apply to query sets, not to objects? Could you say a bit
> more about your
On Wed, Apr 3, 2019 at 2:34 AM Carlton Gibson
wrote:
> Yes, super thanks. Breaking login in development would qualify as a good
> *Why* yes. 🙂
>
> I'll assume we're NOT going to do this, but anyone with input, please do
> comment.
>
Historically I've done something along the lines of
CSRF_COOKI
On Wed, Apr 3, 2019 at 4:31 AM Aldian Fazrihady wrote:
> Many production systems, including mine, are using HTTPS, which
> effectively blocks the capability of attackers from sniffing other people's
> cookies.
>
Closing off opportunities to sniff cookies is more complex than just using
HTTPS, wh
On Sat, Apr 13, 2019 at 1:18 PM Florian Apolloner
wrote:
> Maybe, but I think the benefits outweigh the costs -- and I also do not
> think that it is unnecessary. Our goal has always been to make contributing
> easier, well nowadays black is in the position to do just that.
>
I feel like Black i
As the documentation points out, ModelForm avoids implicitly adding fields
to a form when you haven't told it to, and does so for security reasons.
Mass-assignment bugs have caused significant security issues in the past
for other systems which *did* implicitly support/add fields, and I'd like
to k
Python has a warning system, and Django already uses it for things like
deprecation notices.
I don't like error by default as an approach to this, but a warning (which
is easy to ignore -- it doesn't break your code) would be fine.
--
You received this message because you are subscribed to the G
I like Django's style guide.
I like the *idea* of an autoformatter.
I dislike the particular mostly-unconfigurable style Black enforces, and I
find that several of its rules negatively impact code readability.
So I would be -1 on applying it to Django.
--
You received this message because you
Have you looked at the assertNumQueries assertion?
https://docs.djangoproject.com/en/2.2/topics/testing/tools/#django.test.TransactionTestCase.assertNumQueries
This can let you assert the expected queries and break your tests if
someone accidentally introduces an N+1.
--
You received this messa
On Tue, May 28, 2019 at 9:30 AM Flavio Curella
wrote:
> But there are many situations where a N+1 can get created and people
> usually have don't write tests for (even if they should have). For example,
> assume this model:
>
I guess my question is: if your devs won't check this in tests, why do
On Mon, Jul 15, 2019 at 4:36 AM Ehigie Aito wrote:
> Like I said, in older versions of Django, that variable used to be named
> MIDDLEWARE_CLASSES, if I create a Django project with Python 3.7 and Django
> 2.2.3, its MIDDLEWARE but Python 3.8 and Django 2.2.3 its named
> MIDDLEWARE_CLASSES which
On Mon, Jul 15, 2019 at 4:41 AM Ehigie Aito wrote:
> Not at all, I create all new Django projects from scratch and with pipenv.
> This only happens with Python 3.8.0 b1
>
Open a Python interpreter and type this:
import django
print(django.VERSION)
print(django.__file__)
Make sure VERSION retur
On Mon, Jul 15, 2019 at 10:27 PM Curtis Maloney wrote:
> I think there is certainly a strong case based on "secure by default" to
> include this in core, where it would otherwise face the "it works fine as a
> 3rd party app" barrier to entry.
>
> IMHO it would require, however, that the solutions
I haven't forgotten about this, but it'll likely be another day or two
before I can lay out a proper plan.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving e
On Sat, Jul 27, 2019 at 11:01 AM Florian Apolloner
wrote:
> Not opposed to changing it, but would make {% translateblock %} more sense
> than {% blocktranslate %}?
>
I'm in favor of the change to using the full word "translate". I don't have
a strong opinion on which variant to use for the block
I'm not necessarily opposed to this, but I am a bit skeptical of the
long-term archival utility of forums, in large part due to my experience as
a moderator of some decent-sized ones. I think making them useful for that
purpose is going to require about the same level of manual curation as,
say, th
The main issue with an LTS is that there's no such thing as "long enough".
Upgrading once every three years -- especially when the compatibility
policy now is that if you run on the previous LTS with no deprecation
warnings, you'll also be able to run on the next LTS without errors -- is
not that m
This request is a bit more complicated than I think people
realize. There's no practical way I can see to have the __repr__() of
a QuerySet supply information sufficient to reconstruct it, at least
not in a manner recognizable to most users of the ORM (there's no
internal record of which query meth
I'd be against such a change. I've used a lot of bug trackers, and the only
thing I've learned is there is no good one; replacing one with another just
swaps one set of annoying limitations/frustrations for another. And since
there's a lot of inertia in whatever's currently being used, and it would
The only argument I see for format() over the % operator is that bytes
objects explicitly do not have the format() method and so it'll catch
errors where a bytes object is passed to something expecting a string.
But since we're already Unicode-ifying everything at the boundaries and
have been sinc
Personally I've long been in favor of drastically simplifying the email
regex and essentially telling people that if they want to support
triply-nested comments in a bang-path address they can write their own :)
Is there an actual compelling reason to not just pare it down to "word
characters and/
Apologies for how late in the process this is; job hunt + moving
cross-country ate a lot of my time.
At Django Under the Hood I proposed that for Django 1.10 we try to find
some common best practices for deploying Django on popular
platform-as-a-service (PaaS) solutions, and building support for t
Whee, this thread got big!
The takeaway I'm getting here is that we should be careful about what we
adopt into core and when; I'm going to take a couple days and write up some
notes on what I think a good conservative approach would look like, and ask
for feedback on that.
(spoiler: probably the
On Wed, Aug 31, 2016 at 10:55 AM, Alex Gaynor wrote:
> If these are what qualifies as critical, I don't think this is a good use
> of our time.
>
>
>
Agreed. If those are the critical things, then either Django is really
really good, or there are things it's missing. I suspect there are things
it
For what it's worth, I'm suspicious of threat models which begin with
"assume the DB has already been significantly compromised..." simply
because there's so much someone can do if they gain even read access that
it's not worth expending a ton of effort hardening Django against those
cases.
Simila
I think I once implemented something that dynamically generated model
classes at runtime and prefixed the class names with an underscore.
But I also didn't do much with those models other than set up tables for
them and store/retrieve instances with very simple queries. Also, what I
was doing was
At DUTH this year I opened a ticket to add test-case assertions checking
whether (or not) a signal was sent:
https://code.djangoproject.com/ticket/27447
And corresponding PR:
https://github.com/django/django/pull/7508
The PR has gotten bogged down in API design discussion, so I'd like to hash
t
On Tue, Jan 3, 2017 at 1:14 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Regarding arguments, since signal receivers must accept **kwargs (that’s a
> document requirement), I think it’s acceptable for assertSignalSent to
> ignore unexpected arguments.
>
It's often the case
On Fri, Jan 6, 2017 at 7:03 PM Tim Graham wrote:
> I don't know if matters to anyone, but I guess as long as we support
> Python 3.4 we can't do the type hinting project (PEP 484) since that's new
>
> The typing module also exists standalone on PyPI and thus is pip
> installable for Python 3 < 3.
Please read Florian's message. 2.0 is not going to be "we bumped the major
version, now we can pile in lots of breaking changes".
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this gro
On Sun, Jan 15, 2017 at 1:09 PM, Pkl wrote:
> My bad, if people are guaranteed 2 x 24-month cycles before a feature gets
> removed, it's already much better. However, the same pattern as previously
> appears in docs : "each feature release will continue to have a few
> documented backwards incomp
On Mon, Jan 16, 2017 at 4:47 AM, Adam Johnson wrote:
> We implemented something similar at YPlan but discovered that it wasn't a
> good idea as a system check, because if a dependency changes from another
> devs work then often Django can't even start and run the system check.
> Especially a prob
WSGI is a framework-independent protocol to allow HTTP servers to
communicate with Python applications. It defines a standard API and
serialization mechanism to be used by the HTTP server and the Python
application in order to allow them to work together.
WSGI *only* does plain HTTP. And in fact i
On Thu, Apr 6, 2017 at 5:22 PM, James Pic wrote:
> Do I need this to deploy my projects ? No of course, because I use the
> prettiest way hhihihi ;) I'm more than happy to win a debate
>
Please don't do this. This does not make you look like someone who I could
constructively engage with to try
701 - 800 of 1014 matches
Mail list logo
