Django Enhancement Proposals (DEPs) are a formal way of proposing large feature additions to the Django Web framework (http://www.djangoproject.com/).
See DEP 1 for details.
Django Enhancement Proposals
Django Enhancement Proposals (DEPs) are a formal way of proposing large feature additions to the Django Web framework (http://www.djangoproject.com/).
See DEP 1 for details.
string
I would use slug
The terminology slug is widely used in Django and everybody knows that it is a string without whitespace, slashes and other special characters, while string has a much wider scope of application.
float
First, I don't see any use-case for floats, but more important, numbers of type float sometimes are localized using a comma as a decimal separator instead of the dot. This would allow two different URLs for the same Django view and this therefore can be very confusing.
Postgres10 RC1 has been released recently with some exciting feature such as native partitioning. I have created this DEP to discuss about adding pg10 support to the django.
compare and re assess https://gist.github.com/koniiiik/5408673 too
DEP n: Adopt and Adapt "Tango With Django" as an official tutorial.
Created: 2014-04-14
Author: James Rubino
Status: Draft
Ref:
https://github.com/leifos/tango_with_django
https://github.com/leifos/tango_with_django/blob/master/LICENSE.txt
http://www.tangowithdjango.com/book/chapters/acknowledgements.html
This document has been placed in the public domain.
In DEP 7 at line 28:
28: ...community and core team that the chosen dependency...
The sentence just dangles off into space there...
Unfortunately, there's no way to make a line-comment without editing the document and I'm not sure how verbose/specific you want to be here or whether that was just a repeat of the prior sentence that got left hanging accidentally.
Reflecting on #28 and my first draft DEP in #84 – I’d like the ability to write a DEP in Markdown, as Jacob suggested on the forum: Updating our DEP process / DEP 1. There are a few reasons for this:
I believe it would greatly simplify drafting DEPs if people were able to write them in a language that they’re more familiar with than reStructuredText. It also creates a significant amount of friction if we have to always convert syntax between a forum post and a DEP. We don’t have to rewrite existing DEPs, they’re fine as-is in rST. We would need to:
Here is what DEP 1 has to say about format for reference:
DEPs must be written in `reStructuredText <http://docutils.sourceforge.net/rst.html>`_
(the same format as Django's documentation).
Each DEP should have the following parts:
[…]
#. A preamble -- a rST `field list <http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#field-lists>`_
containing metadata about the DEP, including the DEP number, the names of the
various members of the `DEP team <#forming- the-team>`_, and so forth. See
`DEP Metadata`_ below for specific details.
I’d also recommend dropping the requirement to hard-wrap lines at 80 characters for prose, for future Markdown and reStructuredText DEPs. It makes it harder to read content in the DEP’s source format, and creates silly diffs. If we want to retain specific line break guidelines, I would recommend Semantic Line Breaks.
Can we have documentation for the DEP process as it stands at this point in time, combining what appears to be three different documents?
The README states:
See DEP 1 for details.
Said DEP refers to the Technical Board and to Core Developers, two groups which no longer exist as far as I know.
We have the same issue in Django’s contributor documentation:
Changes to this document require the use of the DEP process, with modifications described in DEP 0010.
DEP 10 is also no longer up-to-date with how Django operates. So – in order to write a DEP, I have to read at least DEP 1, 10, and 12.
@andrewgodwin yes, I decided to write this after watching the presentation you gave at PyConAu 2019
Please consider the usecase where a developer doesn't want to mix sync and async code, but rather has a sync application and a (separate) async application and wants them to have common parts (for example, definitions of the models).
The stated goal was to enable async in django, while preserving backwards compatibility. The accepted approach is to make some parts of django async. Partly because it allows you to have synchronous parts in your async application (that are easier to write), partly because django is big and its migration to async is better to be gradual (thus having a lot of sync parts at start).
To provide that, it is proposed to use something like asgiref.sync_to_async
and asgiref.async_to_sync
adapters. The important detail is that it pins all sync handlers for a given request to a single thread.
Well, it doesn't mean async-only, but it does mean that you cannot mix sync and async code. You can have gunicorn serving the sync handlers and twisted serving the async handlers, both using the same database, config, etc. Actually, you can use that approach today. Just the amount of code you can reuse between sync and async applications is close to 0. That can be improved: the async part of django is unwritten yet, and we have some degree of freedom.
The models are mostly declarative, so conceptually there shouldn't be problems here. The same declarations of models can be used for sync and async code. Let migrations be synchronous only. Let django-admin be synchronous only.
Middleware will have to be implemented differently for sync and async cases. It would be nice if we could still reference same things in the configuration, like this:
MIDDLEWARE = [
'common.SessionMiddleware',
'common.AuthenticationMiddleware',
]
Here common.SessionMiddleware
can be an empty class, an actual implementation being provided separately for sync and async cases.
While I am personally for async-only django, that is configuration-compatible with traditional django, rather then for DEP 9, they do not exclude each other. I guess that a lot of implementation code of DEP 9 will be useful in async-only usecase anyway. I am just asking to add it as a legit usecase to avoid bad API design.
Also, if you know a proper place for this writing, please tell me.
Failure to perform a type conversion against a captured string should result in an
Http404
exception being raised.
Reading the actual implementation django/django#7482 I’m wondering whether this should be Resolver404
instead. Type conversion failure seems symmetric to a regex non-match in the current style, which raises Resolver404
. I understand Resolver404
is implemented as an Http404
subclass, but that seems like implementation detail (or maybe I’m wrong).
I would like to see the barrier to merging a draft DEP be lowered. In particular:
Comments welcome! I can probably look at drafting some changes to DEP0001. In particular the sections around the DEP submission workflow and submitting the draft need some work.
Hi All,
I want to at least outline an alternative proposal based on feedback from James’ PR ( #47 ). And I’d like to propose an actual process for selecting Mergers.
Jacob summarized the biggest problem I see with the current core team: “The problem (as I see it) is that we're currently also recognizing people for (long-)past contributions, giving them power and status that may not be appropriate any more.”
Roughly, I think it should have these features:
Proposal:
Mergers
There are two types of mergers: Core Mergers and Guest Mergers.
Guest Mergers
Core Mergers
Though normally not needed, both DSF board and Tech board have the right make exceptions or to add or remove anyone from any of these roles at any time.
(I like the term “Merger” because it’s the only thing Mergers can do that other people can’t do. “Guest Reviewer” for example makes it sound like other people aren’t allowed to review, and “core team” doesn’t explain what they do as well. You can also be an “active” contributor without being active enough to qualify for the “merger” role. I think “Committer” is also an ok term.)
Also, just like currently, anyone (besides the patch writer) can mark a ticket/patch as “ready for check-in”, and mergers shouldn’t be committing their own stuff without review. I don’t see the need for any changes there. I don’t see any need to change anything about the release process either.
I also think we need better transparency as to who actually has permissions to what, security team and ops teams might also need terms, we somehow need to recognize “moderator” roles on django-users and irc channels, etc, but that’s all out of scope for this proposal.
The new approach to middleware in DEP 5 looks great, making it simpler and more elegant.
One thing that wasn't clear to me was exactly why the old approach had the semantics it did. For example, was there a good reason for making a short-circuited response pass through all the layers (not just the ones above)? Are there any known middleware classes in the Django ecosystem that depend on that functionality? If so, how will this change impact them?
The DEP points out that the new design "allows more powerful idioms that aren't currently possible", but doesn't say whether it makes impossible some idioms that are currently possible. Perhaps it's the case that these foreclosed possibilities (for example, as above, modifying all responses even if the request was short-circuited by a higher layer) aren't useful and don't exist, but either way it would be great to see that explicitly acknowledged in the DEP.
I was confused by the use of the term upstream in this DEP:
That is, when a middleware short-circuits the upstream middleware and view by returning a response, that response will only pass through previous middleware in the list.
and
Similarly, a middleware that modifies the request on the way in and does pass it on upstream can be guaranteed that it will always see the response on the way back out.
If I'm reading this right, I would have used the term downstream. You process a request and pass it downstream to the next level, no?
Upon further reflection, a stream probably isn't a good metaphor for the bi-directional nature of middleware. Higher and lower might be clearer terms, given the presentation of middleware as a series of layers (e.g. the image in the documentation and the ordered list in settings).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.