I can’t log in. When I enter a valid username and password, it just brings up the login page again, with no error messages.¶
│ │ │ │
The login cookie isn’t being set correctly, because the domain of the cookie
│ │ │ │ sent out by Django doesn’t match the domain in your browser. Try setting the
│ │ │ │ SESSION_COOKIE_DOMAIN setting to match your domain. For example, if
│ │ │ │ -you’re going to “https://www.example.com/admin/” in your browser, set
│ │ │ │ +you’re going to «https://www.example.com/admin/» in your browser, set
│ │ │ │ SESSION_COOKIE_DOMAIN='www.example.com'.
│ │ │ │
│ │ │ │
│ │ │ │ -
I can’t log in. When I enter a valid username and password, it brings up the login page again, with a “Please enter a correct username and password” error.¶
│ │ │ │ +
I can’t log in. When I enter a valid username and password, it brings up the login page again, with a «Please enter a correct username and password» error.¶
│ │ │ │
If you’re sure your username and password are correct, make sure your user
│ │ │ │ account has is_active and
│ │ │ │ is_staff set to True. The admin site
│ │ │ │ only allows access to users with those two fields both set to True.
│ │ │ │
│ │ │ │
│ │ │ │
How do I automatically set a field’s value to the user who last edited the object in the admin?¶
│ │ │ │ @@ -111,23 +112,23 @@
│ │ │ │ get_queryset() and
│ │ │ │ has_change_permission() can be used to
│ │ │ │ control the visibility and editability of objects in the admin.
│ │ │ │
│ │ │ │
│ │ │ │
My admin-site CSS and images showed up fine using the development server, but they’re not displaying when using mod_wsgi.¶
│ │ │ │
See serving the admin files
│ │ │ │ -in the “How to use Django with mod_wsgi” documentation.
│ │ │ │ +in the «How to use Django with mod_wsgi» documentation.
│ │ │ │
│ │ │ │
│ │ │ │ -
My “list_filter” contains a ManyToManyField, but the filter doesn’t display.¶
│ │ │ │ +
My «list_filter» contains a ManyToManyField, but the filter doesn’t display.¶
│ │ │ │
Django won’t bother displaying the filter for a ManyToManyField if there
│ │ │ │ are no related objects.
│ │ │ │
For example, if your list_filter
│ │ │ │ includes sites, and there are no sites in your
│ │ │ │ -database, it won’t display a “Site” filter. In that case, filtering by site
│ │ │ │ +database, it won’t display a «Site» filter. In that case, filtering by site
│ │ │ │ would be meaningless.
Inconsistent row counts may be caused by missing foreign key values or a
│ │ │ │ foreign key field incorrectly set to null=False. If you have a record with a
│ │ │ │ ForeignKey pointing to a nonexistent object and
│ │ │ │ @@ -189,53 +190,53 @@
│ │ │ │
How can I get started contributing code to Django?¶
│ │ │ │
Thanks for asking! We’ve written an entire document devoted to this question.
│ │ │ │ It’s titled Contributing to Django.
│ │ │ │
│ │ │ │
│ │ │ │
I submitted a bug fix several weeks ago. Why are you ignoring my contribution?¶
│ │ │ │
Don’t worry: We’re not ignoring you!
│ │ │ │ -
It’s important to understand there is a difference between “a ticket is being
│ │ │ │ -ignored” and “a ticket has not been attended to yet.” Django’s ticket system
│ │ │ │ +
It’s important to understand there is a difference between «a ticket is being
│ │ │ │ +ignored» and «a ticket has not been attended to yet.» Django’s ticket system
│ │ │ │ contains hundreds of open tickets, of various degrees of impact on end-user
│ │ │ │ functionality, and Django’s developers have to review and prioritize.
│ │ │ │
On top of that: the people who work on Django are all volunteers. As a result,
│ │ │ │ the amount of time that we have to work on the framework is limited and will
│ │ │ │ vary from week to week depending on our spare time. If we’re busy, we may not
│ │ │ │ be able to spend as much time on Django as we might want.
│ │ │ │
The best way to make sure tickets do not get hung up on the way to checkin is
│ │ │ │ @@ -157,15 +158,15 @@
│ │ │ │ relative priorities, we are generally trying to consider the needs of the
│ │ │ │ entire community, instead of prioritizing the impact on one particular user.
│ │ │ │ This doesn’t mean that we think your problem is unimportant – just that in the
│ │ │ │ limited time we have available, we will always err on the side of making 10
│ │ │ │ people happy rather than making a single person happy.
│ │ │ │
│ │ │ │
│ │ │ │ -
I’m sure my ticket is absolutely 100% perfect, can I mark it as “Ready For Checkin” myself?¶
│ │ │ │ +
I’m sure my ticket is absolutely 100% perfect, can I mark it as «Ready For Checkin» myself?¶
│ │ │ │
Sorry, no. It’s always better to get another set of eyes on a ticket. If
│ │ │ │ you’re having trouble getting that second set of eyes, see questions above.
│ │ │ │ @@ -95,32 +96,32 @@
│ │ │ │ over two years.
│ │ │ │
In summer 2005, World Online decided to open-source the resulting software,
│ │ │ │ Django. Django would not be possible without a whole host of open-source
│ │ │ │ projects – Apache, Python, and PostgreSQL to name a few – and we’re
│ │ │ │ thrilled to be able to give something back to the open-source community.
│ │ │ │
│ │ │ │
│ │ │ │ -
What does “Django” mean, and how do you pronounce it?¶
│ │ │ │ +
What does «Django» mean, and how do you pronounce it?¶
│ │ │ │
Django is named after Django Reinhardt, a jazz manouche guitarist from the 1930s
│ │ │ │ to early 1950s. To this day, he’s considered one of the best guitarists of all time.
│ │ │ │
Listen to his music. You’ll like it.
│ │ │ │ -
Django is pronounced JANG-oh. Rhymes with FANG-oh. The “D” is silent.
│ │ │ │ +
Django is pronounced JANG-oh. Rhymes with FANG-oh. The «D» is silent.
Yes, it’s quite stable. Companies like Disqus, Instagram, Pinterest, and
│ │ │ │ Mozilla have been using Django for many years. Sites built on Django have
│ │ │ │ weathered traffic spikes of over 50 thousand hits per second.
Yes. Compared to development time, hardware is cheap, and so Django is
│ │ │ │ designed to take advantage of as much hardware as you can throw at it.
│ │ │ │ -
Django uses a “shared-nothing” architecture, which means you can add hardware
│ │ │ │ +
Django uses a «shared-nothing» architecture, which means you can add hardware
│ │ │ │ at any level – database servers, caching servers or web/application servers.
│ │ │ │
The framework cleanly separates components such as its database layer and
│ │ │ │ application layer. And it ships with a simple-yet-powerful
│ │ │ │ cache framework.
BuiltWithDjango.com features a constantly growing list of Django-powered
│ │ │ │ sites.
│ │ │ │
│ │ │ │
│ │ │ │ -
Django appears to be a MVC framework, but you call the Controller the “view”, and the View the “template”. How come you don’t use the standard names?¶
│ │ │ │ +
Django appears to be a MVC framework, but you call the Controller the «view», and the View the «template». How come you don’t use the standard names?¶
│ │ │ │
Well, the standard names are debatable.
│ │ │ │ -
In our interpretation of MVC, the “view” describes the data that gets presented
│ │ │ │ +
In our interpretation of MVC, the «view» describes the data that gets presented
│ │ │ │ to the user. It’s not necessarily how the data looks, but which data is
│ │ │ │ presented. The view describes which data you see, not how you see it. It’s
│ │ │ │ a subtle distinction.
│ │ │ │ -
So, in our case, a “view” is the Python callback function for a particular URL,
│ │ │ │ +
So, in our case, a «view» is the Python callback function for a particular URL,
│ │ │ │ because that callback function describes which data is presented.
│ │ │ │
Furthermore, it’s sensible to separate content from presentation – which is
│ │ │ │ -where templates come in. In Django, a “view” describes which data is presented,
│ │ │ │ +where templates come in. In Django, a «view» describes which data is presented,
│ │ │ │ but a view normally delegates to a template, which describes how the data is
│ │ │ │ presented.
│ │ │ │ -
Where does the “controller” fit in, then? In Django’s case, it’s probably the
│ │ │ │ +
Where does the «controller» fit in, then? In Django’s case, it’s probably the
│ │ │ │ framework itself: the machinery that sends a request to the appropriate view,
│ │ │ │ according to the Django URL configuration.
│ │ │ │ -
If you’re hungry for acronyms, you might say that Django is a “MTV” framework
│ │ │ │ -– that is, “model”, “template”, and “view.” That breakdown makes much more
│ │ │ │ +
If you’re hungry for acronyms, you might say that Django is a «MTV» framework
│ │ │ │ +– that is, «model», «template», and «view.» That breakdown makes much more
│ │ │ │ sense.
│ │ │ │
At the end of the day, it comes down to getting stuff done. And, regardless of
│ │ │ │ how things are named, Django gets stuff done in a way that’s most logical to
│ │ │ │ us.
│ │ │ │
│ │ │ │
│ │ │ │
<Framework X> does <feature Y> – why doesn’t Django?¶
│ │ │ │
We’re well aware that there are other awesome web frameworks out there, and
│ │ │ │ we’re not averse to borrowing ideas where appropriate. However, Django was
│ │ │ │ developed precisely because we were unhappy with the status quo, so please be
│ │ │ │ -aware that “because <Framework X> does it” is not going to be sufficient reason
│ │ │ │ +aware that «because <Framework X> does it» is not going to be sufficient reason
│ │ │ │ to add a given feature to Django.
│ │ │ │
│ │ │ │
│ │ │ │
Why did you write all of Django from scratch, instead of using other Python libraries?¶
│ │ │ │
When Django was originally written, Adrian and Simon spent quite a bit of time
│ │ │ │ exploring the various Python web frameworks available.
│ │ │ │
In our opinion, none of them were completely up to snuff.
No, Django is not a CMS, or any sort of “turnkey product” in and of itself.
│ │ │ │ +
No, Django is not a CMS, or any sort of «turnkey product» in and of itself.
│ │ │ │ It’s a web framework; it’s a programming tool that lets you build websites.
│ │ │ │
For example, it doesn’t make much sense to compare Django to something like
│ │ │ │ Drupal, because Django is something you use to create things like Drupal.
│ │ │ │
Yes, Django’s automatic admin site is fantastic and timesaving – but the admin
│ │ │ │ site is one module of Django the framework. Furthermore, although Django has
│ │ │ │ -special conveniences for building “CMS-y” apps, that doesn’t mean it’s not just
│ │ │ │ -as appropriate for building “non-CMS-y” apps (whatever that means!).
│ │ │ │ +special conveniences for building «CMS-y» apps, that doesn’t mean it’s not just
│ │ │ │ +as appropriate for building «non-CMS-y» apps (whatever that means!).
│ │ │ │
│ │ │ │
│ │ │ │
How can I download the Django documentation to read it offline?¶
│ │ │ │
The Django docs are available in the docs directory of each Django tarball
│ │ │ │ release. These docs are in reST (reStructuredText) format, and each text file
│ │ │ │ corresponds to a web page on the official Django site.
│ │ │ │
Because the documentation is stored in revision control, you
│ │ │ │ @@ -222,19 +223,19 @@
│ │ │ │ software are still a matter of some debate.
│ │ │ │
For example, APA style, would dictate something like:
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ FFAAQQ:: GGeenneerraall_?¶ ************
│ │ │ │ │ ********** WWhhyy ddooeess tthhiiss pprroojjeecctt eexxiisstt??_?¶ **********
│ │ │ │ │ Django grew from a very practical need: World Online, a newspaper web
│ │ │ │ │ operation, is responsible for building intensive web applications on journalism
│ │ │ │ │ deadlines. In the fast-paced newsroom, World Online often has only a matter of
│ │ │ │ │ @@ -15,29 +15,29 @@
│ │ │ │ │ a generic web development framework that let them build web applications more
│ │ │ │ │ and more quickly. They tweaked this framework constantly, adding improvements
│ │ │ │ │ over two years.
│ │ │ │ │ In summer 2005, World Online decided to open-source the resulting software,
│ │ │ │ │ Django. Django would not be possible without a whole host of open-source
│ │ │ │ │ projects – _A_p_a_c_h_e, _P_y_t_h_o_n, and _P_o_s_t_g_r_e_S_Q_L to name a few – and we’re thrilled to
│ │ │ │ │ be able to give something back to the open-source community.
│ │ │ │ │ -********** WWhhaatt ddooeess ?“DDjjaannggoo?” mmeeaann,, aanndd hhooww ddoo yyoouu pprroonnoouunnccee iitt??_?¶ **********
│ │ │ │ │ +********** WWhhaatt ddooeess ?«DDjjaannggoo?» mmeeaann,, aanndd hhooww ddoo yyoouu pprroonnoouunnccee iitt??_?¶ **********
│ │ │ │ │ Django is named after _D_j_a_n_g_o_ _R_e_i_n_h_a_r_d_t, a jazz manouche guitarist from the
│ │ │ │ │ 1930s to early 1950s. To this day, he’s considered one of the best guitarists
│ │ │ │ │ of all time.
│ │ │ │ │ Listen to his music. You’ll like it.
│ │ │ │ │ -Django is pronounced JJAANNGG-oh. Rhymes with FANG-oh. The “D” is silent.
│ │ │ │ │ +Django is pronounced JJAANNGG-oh. Rhymes with FANG-oh. The «D» is silent.
│ │ │ │ │ We’ve also recorded an _a_u_d_i_o_ _c_l_i_p_ _o_f_ _t_h_e_ _p_r_o_n_u_n_c_i_a_t_i_o_n.
│ │ │ │ │ ********** IIss DDjjaannggoo ssttaabbllee??_?¶ **********
│ │ │ │ │ Yes, it’s quite stable. Companies like Disqus, Instagram, Pinterest, and
│ │ │ │ │ Mozilla have been using Django for many years. Sites built on Django have
│ │ │ │ │ weathered traffic spikes of over 50 thousand hits per second.
│ │ │ │ │ ********** DDooeess DDjjaannggoo ssccaallee??_?¶ **********
│ │ │ │ │ Yes. Compared to development time, hardware is cheap, and so Django is designed
│ │ │ │ │ to take advantage of as much hardware as you can throw at it.
│ │ │ │ │ -Django uses a “shared-nothing” architecture, which means you can add hardware
│ │ │ │ │ +Django uses a «shared-nothing» architecture, which means you can add hardware
│ │ │ │ │ at any level – database servers, caching servers or web/application servers.
│ │ │ │ │ The framework cleanly separates components such as its database layer and
│ │ │ │ │ application layer. And it ships with a simple-yet-powerful _c_a_c_h_e_ _f_r_a_m_e_w_o_r_k.
│ │ │ │ │ ********** WWhhoo?’ss bbeehhiinndd tthhiiss??_?¶ **********
│ │ │ │ │ Django was originally developed at World Online, the web department of a
│ │ │ │ │ newspaper in Lawrence, Kansas, USA. Django’s now run by an international _t_e_a_m
│ │ │ │ │ _o_f_ _v_o_l_u_n_t_e_e_r_s.
│ │ │ │ │ @@ -47,40 +47,40 @@
│ │ │ │ │ ********** WWhhyy ddooeess DDjjaannggoo iinncclluuddee PPyytthhoonn?’ss lliicceennssee ffiillee??_?¶ **********
│ │ │ │ │ Django includes code from the Python standard library. Python is distributed
│ │ │ │ │ under a permissive open source license. _A_ _c_o_p_y_ _o_f_ _t_h_e_ _P_y_t_h_o_n_ _l_i_c_e_n_s_e is
│ │ │ │ │ included with Django for compliance with Python’s terms.
│ │ │ │ │ ********** WWhhiicchh ssiitteess uussee DDjjaannggoo??_?¶ **********
│ │ │ │ │ _B_u_i_l_t_W_i_t_h_D_j_a_n_g_o_._c_o_m features a constantly growing list of Django-powered sites.
│ │ │ │ │ ********** DDjjaannggoo aappppeeaarrss ttoo bbee aa MMVVCC ffrraammeewwoorrkk,, bbuutt yyoouu ccaallll tthhee CCoonnttrroolllleerr tthhee
│ │ │ │ │ -?“vviieeww?”,, aanndd tthhee VViieeww tthhee ?“tteemmppllaattee?”.. HHooww ccoommee yyoouu ddoonn?’tt uussee tthhee ssttaannddaarrdd
│ │ │ │ │ +?«vviieeww?»,, aanndd tthhee VViieeww tthhee ?«tteemmppllaattee?».. HHooww ccoommee yyoouu ddoonn?’tt uussee tthhee ssttaannddaarrdd
│ │ │ │ │ nnaammeess??_?¶ **********
│ │ │ │ │ Well, the standard names are debatable.
│ │ │ │ │ -In our interpretation of MVC, the “view” describes the data that gets presented
│ │ │ │ │ +In our interpretation of MVC, the «view» describes the data that gets presented
│ │ │ │ │ to the user. It’s not necessarily hhooww the data llooookkss, but wwhhiicchh data is
│ │ │ │ │ presented. The view describes wwhhiicchh ddaattaa yyoouu sseeee, not hhooww yyoouu sseeee iitt.. It’s a
│ │ │ │ │ subtle distinction.
│ │ │ │ │ -So, in our case, a “view” is the Python callback function for a particular URL,
│ │ │ │ │ +So, in our case, a «view» is the Python callback function for a particular URL,
│ │ │ │ │ because that callback function describes which data is presented.
│ │ │ │ │ Furthermore, it’s sensible to separate content from presentation – which is
│ │ │ │ │ -where templates come in. In Django, a “view” describes which data is presented,
│ │ │ │ │ +where templates come in. In Django, a «view» describes which data is presented,
│ │ │ │ │ but a view normally delegates to a template, which describes hhooww the data is
│ │ │ │ │ presented.
│ │ │ │ │ -Where does the “controller” fit in, then? In Django’s case, it’s probably the
│ │ │ │ │ +Where does the «controller» fit in, then? In Django’s case, it’s probably the
│ │ │ │ │ framework itself: the machinery that sends a request to the appropriate view,
│ │ │ │ │ according to the Django URL configuration.
│ │ │ │ │ -If you’re hungry for acronyms, you might say that Django is a “MTV” framework –
│ │ │ │ │ -that is, “model”, “template”, and “view.” That breakdown makes much more sense.
│ │ │ │ │ +If you’re hungry for acronyms, you might say that Django is a «MTV» framework –
│ │ │ │ │ +that is, «model», «template», and «view.» That breakdown makes much more sense.
│ │ │ │ │ At the end of the day, it comes down to getting stuff done. And, regardless of
│ │ │ │ │ how things are named, Django gets stuff done in a way that’s most logical to
│ │ │ │ │ us.
│ │ │ │ │ ********** <> ddooeess <> ?– wwhhyy ddooeessnn?’tt DDjjaannggoo??_?¶ **********
│ │ │ │ │ We’re well aware that there are other awesome web frameworks out there, and
│ │ │ │ │ we’re not averse to borrowing ideas where appropriate. However, Django was
│ │ │ │ │ developed precisely because we were unhappy with the status quo, so please be
│ │ │ │ │ -aware that “because does it” is not going to be sufficient reason
│ │ │ │ │ +aware that «because does it» is not going to be sufficient reason
│ │ │ │ │ to add a given feature to Django.
│ │ │ │ │ ********** WWhhyy ddiidd yyoouu wwrriittee aallll ooff DDjjaannggoo ffrroomm ssccrraattcchh,, iinnsstteeaadd ooff uussiinngg ootthheerr
│ │ │ │ │ PPyytthhoonn lliibbrraarriieess??_?¶ **********
│ │ │ │ │ When Django was originally written, Adrian and Simon spent quite a bit of time
│ │ │ │ │ exploring the various Python web frameworks available.
│ │ │ │ │ In our opinion, none of them were completely up to snuff.
│ │ │ │ │ We’re picky. You might even call us perfectionists. (With deadlines.)
│ │ │ │ │ @@ -91,22 +91,22 @@
│ │ │ │ │ production settings – and our own code met our needs delightfully.
│ │ │ │ │ In most cases, however, we found that existing frameworks/tools inevitably had
│ │ │ │ │ some sort of fundamental, fatal flaw that made us squeamish. No tool fit our
│ │ │ │ │ philosophies 100%.
│ │ │ │ │ Like we said: We’re picky.
│ │ │ │ │ We’ve documented our philosophies on the _d_e_s_i_g_n_ _p_h_i_l_o_s_o_p_h_i_e_s_ _p_a_g_e.
│ │ │ │ │ ********** IIss DDjjaannggoo aa ccoonntteenntt--mmaannaaggeemmeenntt--ssyysstteemm ((CCMMSS))??_?¶ **********
│ │ │ │ │ -No, Django is not a CMS, or any sort of “turnkey product” in and of itself.
│ │ │ │ │ +No, Django is not a CMS, or any sort of «turnkey product» in and of itself.
│ │ │ │ │ It’s a web framework; it’s a programming tool that lets you build websites.
│ │ │ │ │ For example, it doesn’t make much sense to compare Django to something like
│ │ │ │ │ _D_r_u_p_a_l, because Django is something you use to ccrreeaattee things like Drupal.
│ │ │ │ │ Yes, Django’s automatic admin site is fantastic and timesaving – but the admin
│ │ │ │ │ site is one module of Django the framework. Furthermore, although Django has
│ │ │ │ │ -special conveniences for building “CMS-y” apps, that doesn’t mean it’s not just
│ │ │ │ │ -as appropriate for building “non-CMS-y” apps (whatever that means!).
│ │ │ │ │ +special conveniences for building «CMS-y» apps, that doesn’t mean it’s not just
│ │ │ │ │ +as appropriate for building «non-CMS-y» apps (whatever that means!).
│ │ │ │ │ ********** HHooww ccaann II ddoowwnnllooaadd tthhee DDjjaannggoo ddooccuummeennttaattiioonn ttoo rreeaadd iitt oofffflliinnee??_?¶ **********
│ │ │ │ │ The Django docs are available in the docs directory of each Django tarball
│ │ │ │ │ release. These docs are in reST (reStructuredText) format, and each text file
│ │ │ │ │ corresponds to a web page on the official Django site.
│ │ │ │ │ Because the documentation is _s_t_o_r_e_d_ _i_n_ _r_e_v_i_s_i_o_n_ _c_o_n_t_r_o_l, you can browse
│ │ │ │ │ documentation changes just like you can browse code changes.
│ │ │ │ │ Technically, the docs on Django’s site are generated from the latest
│ │ │ │ │ @@ -118,42 +118,42 @@
│ │ │ │ │ formats can vary wildly between publications, and citation standards for
│ │ │ │ │ software are still a matter of some debate.
│ │ │ │ │ For example, _A_P_A_ _s_t_y_l_e, would dictate something like:
│ │ │ │ │ Django (Version 1.5) [Computer Software]. (2013). Retrieved from https://
│ │ │ │ │ www.djangoproject.com/.
│ │ │ │ │ However, the only true guide is what your publisher will accept, so get a copy
│ │ │ │ │ of those guidelines and fill in the gaps as best you can.
│ │ │ │ │ -If your referencing style guide requires a publisher name, use “Django Software
│ │ │ │ │ -Foundation”.
│ │ │ │ │ -If you need a publishing location, use “Lawrence, Kansas”.
│ │ │ │ │ +If your referencing style guide requires a publisher name, use «Django Software
│ │ │ │ │ +Foundation».
│ │ │ │ │ +If you need a publishing location, use «Lawrence, Kansas».
│ │ │ │ │ If you need a web address, use _h_t_t_p_s_:_/_/_w_w_w_._d_j_a_n_g_o_p_r_o_j_e_c_t_._c_o_m_/.
│ │ │ │ │ -If you need a name, just use “Django”, without any tagline.
│ │ │ │ │ +If you need a name, just use «Django», without any tagline.
│ │ │ │ │ If you need a publication date, use the year of release of the version you’re
│ │ │ │ │ referencing (e.g., 2013 for v1.5)
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ * _F_A_Q_:_ _G_e_n_e_r_a_l
│ │ │ │ │ o _W_h_y_ _d_o_e_s_ _t_h_i_s_ _p_r_o_j_e_c_t_ _e_x_i_s_t_?
│ │ │ │ │ - o _W_h_a_t_ _d_o_e_s_ _“_D_j_a_n_g_o_”_ _m_e_a_n_,_ _a_n_d_ _h_o_w_ _d_o_ _y_o_u_ _p_r_o_n_o_u_n_c_e_ _i_t_?
│ │ │ │ │ + o _W_h_a_t_ _d_o_e_s_ _«_D_j_a_n_g_o_»_ _m_e_a_n_,_ _a_n_d_ _h_o_w_ _d_o_ _y_o_u_ _p_r_o_n_o_u_n_c_e_ _i_t_?
│ │ │ │ │ o _I_s_ _D_j_a_n_g_o_ _s_t_a_b_l_e_?
│ │ │ │ │ o _D_o_e_s_ _D_j_a_n_g_o_ _s_c_a_l_e_?
│ │ │ │ │ o _W_h_o_’_s_ _b_e_h_i_n_d_ _t_h_i_s_?
│ │ │ │ │ o _H_o_w_ _i_s_ _D_j_a_n_g_o_ _l_i_c_e_n_s_e_d_?
│ │ │ │ │ o _W_h_y_ _d_o_e_s_ _D_j_a_n_g_o_ _i_n_c_l_u_d_e_ _P_y_t_h_o_n_’_s_ _l_i_c_e_n_s_e_ _f_i_l_e_?
│ │ │ │ │ o _W_h_i_c_h_ _s_i_t_e_s_ _u_s_e_ _D_j_a_n_g_o_?
│ │ │ │ │ o _D_j_a_n_g_o_ _a_p_p_e_a_r_s_ _t_o_ _b_e_ _a_ _M_V_C_ _f_r_a_m_e_w_o_r_k_,_ _b_u_t_ _y_o_u_ _c_a_l_l_ _t_h_e_ _C_o_n_t_r_o_l_l_e_r
│ │ │ │ │ - _t_h_e_ _“_v_i_e_w_”_,_ _a_n_d_ _t_h_e_ _V_i_e_w_ _t_h_e_ _“_t_e_m_p_l_a_t_e_”_._ _H_o_w_ _c_o_m_e_ _y_o_u_ _d_o_n_’_t_ _u_s_e_ _t_h_e
│ │ │ │ │ + _t_h_e_ _«_v_i_e_w_»_,_ _a_n_d_ _t_h_e_ _V_i_e_w_ _t_h_e_ _«_t_e_m_p_l_a_t_e_»_._ _H_o_w_ _c_o_m_e_ _y_o_u_ _d_o_n_’_t_ _u_s_e_ _t_h_e
│ │ │ │ │ _s_t_a_n_d_a_r_d_ _n_a_m_e_s_?
│ │ │ │ │ o _<_F_r_a_m_e_w_o_r_k_ _X_>_ _d_o_e_s_ _<_f_e_a_t_u_r_e_ _Y_>_ _–_ _w_h_y_ _d_o_e_s_n_’_t_ _D_j_a_n_g_o_?
│ │ │ │ │ o _W_h_y_ _d_i_d_ _y_o_u_ _w_r_i_t_e_ _a_l_l_ _o_f_ _D_j_a_n_g_o_ _f_r_o_m_ _s_c_r_a_t_c_h_,_ _i_n_s_t_e_a_d_ _o_f_ _u_s_i_n_g
│ │ │ │ │ _o_t_h_e_r_ _P_y_t_h_o_n_ _l_i_b_r_a_r_i_e_s_?
│ │ │ │ │ o _I_s_ _D_j_a_n_g_o_ _a_ _c_o_n_t_e_n_t_-_m_a_n_a_g_e_m_e_n_t_-_s_y_s_t_e_m_ _(_C_M_S_)_?
│ │ │ │ │ o _H_o_w_ _c_a_n_ _I_ _d_o_w_n_l_o_a_d_ _t_h_e_ _D_j_a_n_g_o_ _d_o_c_u_m_e_n_t_a_t_i_o_n_ _t_o_ _r_e_a_d_ _i_t_ _o_f_f_l_i_n_e_?
│ │ │ │ │ o _H_o_w_ _d_o_ _I_ _c_i_t_e_ _D_j_a_n_g_o_?
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _D_j_a_n_g_o_ _F_A_Q
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _F_A_Q_:_ _I_n_s_t_a_l_l_a_t_i_o_n
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/faq/help.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - FAQ: Getting Help — Django 5.1b1 documentation
│ │ │ │ + FAQ: Getting Help — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,15 +54,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
First, please check if your question is answered on the FAQ. Also, search for answers using your favorite search engine, and
│ │ │ │ in the forum.
│ │ │ │
If you can’t find an answer, please take a few minutes to formulate your
│ │ │ │ question well. Explaining the problems you are facing clearly will help others
│ │ │ │ help you. See the StackOverflow guide on asking good questions.
│ │ │ │
Then, please post it in one of the following channels:
│ │ │ │
│ │ │ │ -
The Django Forum section “Using Django”. This is for web-based
│ │ │ │ +
The Django Forum section «Using Django». This is for web-based
│ │ │ │ discussions.
│ │ │ │
The django-users mailing list. This is for email-based discussions.
django-admin should be on your system path if you
│ │ │ │ installed Django via pip. If it’s not in your path, ensure you have your
│ │ │ │ virtual environment activated and you can try running the equivalent command
│ │ │ │ python-mdjango.
If you’re using macOS, you may see the message “permission denied” when
│ │ │ │ +
If you’re using macOS, you may see the message «permission denied» when
│ │ │ │ you try to run django-admin. This is because, on Unix-based systems like
│ │ │ │ -macOS, a file must be marked as “executable” before it can be run as a program.
│ │ │ │ +macOS, a file must be marked as «executable» before it can be run as a program.
│ │ │ │ To do this, open Terminal.app and navigate (using the cd command) to the
│ │ │ │ directory where django-admin is installed, then
│ │ │ │ run the command sudochmod+xdjango-admin.
UnicodeDecodeError: 'ascii' codec can't decode byte 0x?? in position ?:
│ │ │ │ ordinal not in range(128)
│ │ │ │
│ │ │ │
│ │ │ │
The resolution mostly depends on the context, however here are two common
│ │ │ │ pitfalls producing this error:
│ │ │ │
│ │ │ │ -
Your system locale may be a default ASCII locale, like the “C” locale on
│ │ │ │ +
Your system locale may be a default ASCII locale, like the «C» locale on
│ │ │ │ UNIX-like systems (can be checked by the locale command). If it’s the
│ │ │ │ case, please refer to your system documentation to learn how you can change
│ │ │ │ this to a UTF-8 locale.
A Python package – i.e. a directory of code – that contains all the
│ │ │ │ settings for an instance of Django. This would include database
│ │ │ │ configuration, Django-specific options and application-specific
│ │ │ │ settings.
Also known as «managed attributes», and a feature of Python since
│ │ │ │ version 2.2. This is a neat way to implement attributes whose usage
│ │ │ │ resembles attribute access, but whose implementation uses method calls.
│ │ │ │ @@ -124,15 +125,15 @@
│ │ │ │ AUTHENTICATION_BACKENDS list will use ModelBackend as a fallback
│ │ │ │ if REMOTE_USER is absent, which will solve these issues.
│ │ │ │
Django’s user management, such as the views in contrib.admin and
│ │ │ │ the createsuperuser management command, doesn’t integrate with
│ │ │ │ remote users. These interfaces work with users stored in the database
│ │ │ │ regardless of AUTHENTICATION_BACKENDS.
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
Since the RemoteUserBackend inherits from ModelBackend, you will
│ │ │ │ still have all of the same permissions checking that is implemented in
│ │ │ │ ModelBackend.
Be very careful if using a RemoteUserMiddleware subclass with a custom
│ │ │ │ HTTP header. You must be sure that your front-end web server always sets or
│ │ │ │ strips that header based on the appropriate authentication checks, never
│ │ │ │ -permitting an end-user to submit a fake (or “spoofed”) header value. Since
│ │ │ │ +permitting an end-user to submit a fake (or «spoofed») header value. Since
│ │ │ │ the HTTP headers X-Auth-User and X-Auth_User (for example) both
│ │ │ │ normalize to the HTTP_X_AUTH_USER key in request.META, you must
│ │ │ │ also check that your web server doesn’t allow a spoofed header using
│ │ │ │ underscores in place of dashes.
│ │ │ │
This warning doesn’t apply to RemoteUserMiddleware in its default
│ │ │ │ configuration with header='REMOTE_USER', since a key that doesn’t
│ │ │ │ start with HTTP_ in request.META can only be set by your WSGI
│ │ │ │ @@ -202,47 +203,47 @@
│ │ │ │
The CSRF token is also present in the DOM in a masked form, but only if
│ │ │ │ explicitly included using csrf_token in a template. The cookie
│ │ │ │ contains the canonical, unmasked token. The
│ │ │ │ CsrfViewMiddleware will accept either.
│ │ │ │ However, in order to protect against BREACH attacks, it’s recommended to
│ │ │ │ use a masked token.
│ │ │ │
│ │ │ │
│ │ │ │ -
Warning
│ │ │ │ +
Avvertimento
│ │ │ │
If your view is not rendering a template containing the csrf_token
│ │ │ │ template tag, Django might not set the CSRF token cookie. This is common in
│ │ │ │ cases where forms are dynamically added to the page. To address this case,
│ │ │ │ Django provides a view decorator which forces setting of the cookie:
│ │ │ │ ensure_csrf_cookie().
│ │ │ │
│ │ │ │
│ │ │ │ @@ -207,20 +208,20 @@
│ │ │ │
Rather than adding CsrfViewMiddleware as a blanket protection, you can use
│ │ │ │ the csrf_protect() decorator, which has
│ │ │ │ exactly the same functionality, on particular views that need the protection.
│ │ │ │ It must be used both on views that insert the CSRF token in the output, and
│ │ │ │ on those that accept the POST form data. (These are often the same view
│ │ │ │ function, but not always).
│ │ │ │
Use of the decorator by itself is not recommended, since if you forget to
│ │ │ │ -use it, you will have a security hole. The ‘belt and braces’ strategy of using
│ │ │ │ +use it, you will have a security hole. The “belt and braces” strategy of using
│ │ │ │ both is fine, and will incur minimal overhead.
By default, a ‘403 Forbidden’ response is sent to the user if an incoming
│ │ │ │ +
By default, a “403 Forbidden” response is sent to the user if an incoming
│ │ │ │ request fails the checks performed by CsrfViewMiddleware. This should
│ │ │ │ usually only be seen when there is a genuine Cross Site Request Forgery, or
│ │ │ │ when, due to a programming error, the CSRF token has not been included with a
│ │ │ │ POST form.
│ │ │ │
The error page, however, is not very friendly, so you may want to provide your
│ │ │ │ own view for handling this condition. To do this, set the
│ │ │ │ CSRF_FAILURE_VIEW setting.
│ │ │ │ @@ -166,15 +167,15 @@
│ │ │ │ application where we want to make use of the abs() operator.
│ │ │ │ We have an Experiment model which records a start value, end value, and the
│ │ │ │ change (start - end). We would like to find all experiments where the change
│ │ │ │ was equal to a certain amount (Experiment.objects.filter(change__abs=27)),
│ │ │ │ or where it did not exceed a certain amount
│ │ │ │ (Experiment.objects.filter(change__abs__lt=27)).
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
This example is somewhat contrived, but it nicely demonstrates the range of
│ │ │ │ functionality which is possible in a database backend independent manner,
│ │ │ │ and without duplicating functionality already in Django.
│ │ │ │
│ │ │ │
We will start by writing an AbsoluteValue transformer. This will use the SQL
│ │ │ │ function ABS() to transform the value before comparison:
Notice also that as both sides are used multiple times in the query the params
│ │ │ │ need to contain lhs_params and rhs_params multiple times.
│ │ │ │
The final query does the inversion (27 to -27) directly in the
│ │ │ │ database. The reason for doing this is that if the self.rhs is something else
│ │ │ │ than a plain integer value (for example an F() reference) we can’t do the
│ │ │ │ transformations in Python.
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
In fact, most lookups with __abs could be implemented as range queries
│ │ │ │ like this, and on most database backends it is likely to be more sensible to
│ │ │ │ do so as you can make use of the indexes. However with PostgreSQL you may
│ │ │ │ want to add an index on abs(change) which would allow these queries to
│ │ │ │ be very efficient.
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ HHooww ttoo wwrriittee ccuussttoomm llooookkuuppss_?¶ ************
│ │ │ │ │ Django offers a wide variety of _b_u_i_l_t_-_i_n_ _l_o_o_k_u_p_s for filtering (for example,
│ │ │ │ │ exact and icontains). This documentation explains how to write custom lookups
│ │ │ │ │ and how to alter the working of existing lookups. For the API references of
│ │ │ │ │ lookups, see the _L_o_o_k_u_p_ _A_P_I_ _r_e_f_e_r_e_n_c_e.
│ │ │ │ │ @@ -74,15 +74,15 @@
│ │ │ │ │ The custom lookup above is great, but in some cases you may want to be able to
│ │ │ │ │ chain lookups together. For example, let’s suppose we are building an
│ │ │ │ │ application where we want to make use of the abs() operator. We have an
│ │ │ │ │ Experiment model which records a start value, end value, and the change (start
│ │ │ │ │ - end). We would like to find all experiments where the change was equal to a
│ │ │ │ │ certain amount (Experiment.objects.filter(change__abs=27)), or where it did not
│ │ │ │ │ exceed a certain amount (Experiment.objects.filter(change__abs__lt=27)).
│ │ │ │ │ -Note
│ │ │ │ │ +Nota
│ │ │ │ │ This example is somewhat contrived, but it nicely demonstrates the range of
│ │ │ │ │ functionality which is possible in a database backend independent manner, and
│ │ │ │ │ without duplicating functionality already in Django.
│ │ │ │ │ We will start by writing an AbsoluteValue transformer. This will use the SQL
│ │ │ │ │ function ABS() to transform the value before comparison:
│ │ │ │ │ from django.db.models import Transform
│ │ │ │ │
│ │ │ │ │ @@ -159,15 +159,15 @@
│ │ │ │ │ AbsoluteValue lookup, that is the lhs is always an instance of AbsoluteValue.
│ │ │ │ │ Notice also that as both sides are used multiple times in the query the params
│ │ │ │ │ need to contain lhs_params and rhs_params multiple times.
│ │ │ │ │ The final query does the inversion (27 to -27) directly in the database. The
│ │ │ │ │ reason for doing this is that if the self.rhs is something else than a plain
│ │ │ │ │ integer value (for example an F() reference) we can’t do the transformations in
│ │ │ │ │ Python.
│ │ │ │ │ -Note
│ │ │ │ │ +Nota
│ │ │ │ │ In fact, most lookups with __abs could be implemented as range queries like
│ │ │ │ │ this, and on most database backends it is likely to be more sensible to do so
│ │ │ │ │ as you can make use of the indexes. However with PostgreSQL you may want to add
│ │ │ │ │ an index on abs(change) which would allow these queries to be very efficient.
│ │ │ │ │ ********** AA bbiillaatteerraall ttrraannssffoorrmmeerr eexxaammppllee_?¶ **********
│ │ │ │ │ The AbsoluteValue example we discussed previously is a transformation which
│ │ │ │ │ applies to the left-hand side of the lookup. There may be some cases where you
│ │ │ │ │ @@ -257,16 +257,16 @@
│ │ │ │ │ * _H_o_w_ _t_o_ _w_r_i_t_e_ _c_u_s_t_o_m_ _l_o_o_k_u_p_s
│ │ │ │ │ o _A_ _l_o_o_k_u_p_ _e_x_a_m_p_l_e
│ │ │ │ │ o _A_ _t_r_a_n_s_f_o_r_m_e_r_ _e_x_a_m_p_l_e
│ │ │ │ │ o _W_r_i_t_i_n_g_ _a_n_ _e_f_f_i_c_i_e_n_t_ _a_b_s_____l_t_ _l_o_o_k_u_p
│ │ │ │ │ o _A_ _b_i_l_a_t_e_r_a_l_ _t_r_a_n_s_f_o_r_m_e_r_ _e_x_a_m_p_l_e
│ │ │ │ │ o _W_r_i_t_i_n_g_ _a_l_t_e_r_n_a_t_i_v_e_ _i_m_p_l_e_m_e_n_t_a_t_i_o_n_s_ _f_o_r_ _e_x_i_s_t_i_n_g_ _l_o_o_k_u_p_s
│ │ │ │ │ o _H_o_w_ _D_j_a_n_g_o_ _d_e_t_e_r_m_i_n_e_s_ _t_h_e_ _l_o_o_k_u_p_s_ _a_n_d_ _t_r_a_n_s_f_o_r_m_s_ _w_h_i_c_h_ _a_r_e_ _u_s_e_d
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _H_o_w_ _t_o_ _c_r_e_a_t_e_ _c_u_s_t_o_m_ _m_o_d_e_l_ _f_i_e_l_d_s
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _H_o_w_ _t_o_ _i_m_p_l_e_m_e_n_t_ _a_ _c_u_s_t_o_m_ _t_e_m_p_l_a_t_e_ _b_a_c_k_e_n_d
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/howto/custom-management-commands.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - How to create custom django-admin commands — Django 5.1b1 documentation
│ │ │ │ + How to create custom django-admin commands — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,25 +54,25 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
When you are using management commands and wish to provide console
│ │ │ │ output, you should write to self.stdout and self.stderr,
│ │ │ │ instead of printing to stdout and stderr directly. By
│ │ │ │ using these proxies, it becomes much easier to test your custom
│ │ │ │ command. Note also that you don’t need to end messages with a newline
│ │ │ │ character, it will be added automatically, unless you specify the ending
│ │ │ │ parameter:
│ │ │ │ @@ -230,15 +231,15 @@
│ │ │ │ INSTALLED_APPS) which imports the Command of the overridden
│ │ │ │ command.
│ │ │ │
│ │ │ │
│ │ │ │
The base class from which all management commands ultimately derive.
│ │ │ │
Use this class if you want access to all of the mechanisms which
│ │ │ │ parse the command-line arguments and work out what code to call in
│ │ │ │ response; if you don’t need to change any of that behavior,
│ │ │ │ consider using one of its subclasses.
If your command defines mandatory positional arguments, you can customize
│ │ │ │ the message error returned in the case of missing arguments. The default is
│ │ │ │ -output by argparse (“too few arguments”).
│ │ │ │ +output by argparse («too few arguments»).
│ │ │ │
See Syntax coloring to learn how to modify the color palette and to
│ │ │ │ -see the available styles (use uppercased versions of the “roles” described
│ │ │ │ +see the available styles (use uppercased versions of the «roles» described
│ │ │ │ in that section).
│ │ │ │
If you pass the --no-color option when running your command, all
│ │ │ │ self.style() calls will return the original string uncolored.
Entry point to add parser arguments to handle command line arguments passed
│ │ │ │ to the command. Custom commands should override this method to add both
│ │ │ │ positional and optional arguments accepted by the command. Calling
│ │ │ │ super() is not needed when directly subclassing BaseCommand.
Returns the Django version, which should be correct for all built-in Django
│ │ │ │ commands. User-supplied commands can override this method to return their
│ │ │ │ own version.
Tries to execute this command, performing system checks if needed (as
│ │ │ │ controlled by the requires_system_checks attribute). If the command
│ │ │ │ raises a CommandError, it’s intercepted and printed to stderr.
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Calling a management command in your code
│ │ │ │
execute() should not be called directly from your code to execute a
│ │ │ │ command. Use call_command() instead.
Uses the system check framework to inspect the entire Django project for
│ │ │ │ potential problems. Serious problems are raised as a CommandError;
│ │ │ │ warnings are output to stderr; minor notifications are output to
│ │ │ │ stdout.
│ │ │ │
If app_configs and tags are both None, all system checks are
│ │ │ │ performed except deployment and database related checks. tags can be a
│ │ │ │ list of check tags, like compatibility or models.
Exception class indicating a problem while executing a management command.
│ │ │ │
If this exception is raised during the execution of a management command from a
│ │ │ │ command line console, it will be caught and turned into a nicely-printed error
│ │ │ │ message to the appropriate output stream (i.e., stderr); as a result,
│ │ │ │ raising this exception (with a sensible description of the error) is the
│ │ │ │ @@ -487,47 +488,47 @@
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ HHooww ttoo ccrreeaattee ccuussttoomm ddjjaannggoo--aaddmmiinn ccoommmmaannddss_?¶ ************
│ │ │ │ │ Applications can register their own actions with manage.py. For example, you
│ │ │ │ │ might want to add a manage.py action for a Django app that you’re distributing.
│ │ │ │ │ In this document, we will be building a custom closepoll command for the polls
│ │ │ │ │ application from the _t_u_t_o_r_i_a_l.
│ │ │ │ │ @@ -50,15 +50,15 @@
│ │ │ │ │
│ │ │ │ │ poll.opened = False
│ │ │ │ │ poll.save()
│ │ │ │ │
│ │ │ │ │ self.stdout.write(
│ │ │ │ │ self.style.SUCCESS('Successfully closed poll "%s"' % poll_id)
│ │ │ │ │ )
│ │ │ │ │ -Note
│ │ │ │ │ +Nota
│ │ │ │ │ When you are using management commands and wish to provide console output, you
│ │ │ │ │ should write to self.stdout and self.stderr, instead of printing to stdout and
│ │ │ │ │ stderr directly. By using these proxies, it becomes much easier to test your
│ │ │ │ │ custom command. Note also that you don’t need to end messages with a newline
│ │ │ │ │ character, it will be added automatically, unless you specify the ending
│ │ │ │ │ parameter:
│ │ │ │ │ self.stdout.write("Unterminated line", ending="")
│ │ │ │ │ @@ -120,15 +120,15 @@
│ │ │ │ │ In other words, to override a command, the new command must have the same name
│ │ │ │ │ and its app must be before the overridden command’s app in _I_N_S_T_A_L_L_E_D___A_P_P_S.
│ │ │ │ │ Management commands from third-party apps that have been unintentionally
│ │ │ │ │ overridden can be made available under a new name by creating a new command in
│ │ │ │ │ one of your project’s apps (ordered before the third-party app in
│ │ │ │ │ _I_N_S_T_A_L_L_E_D___A_P_P_S) which imports the Command of the overridden command.
│ │ │ │ │ ********** CCoommmmaanndd oobbjjeeccttss_?¶ **********
│ │ │ │ │ - ccllaassss BaseCommand_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + ccllaassss BaseCommand_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ The base class from which all management commands ultimately derive.
│ │ │ │ │ Use this class if you want access to all of the mechanisms which parse the
│ │ │ │ │ command-line arguments and work out what code to call in response; if you don’t
│ │ │ │ │ need to change any of that behavior, consider using one of its _s_u_b_c_l_a_s_s_e_s.
│ │ │ │ │ Subclassing the _B_a_s_e_C_o_m_m_a_n_d class requires that you implement the _h_a_n_d_l_e_(_)
│ │ │ │ │ method.
│ │ │ │ │ ******** AAttttrriibbuutteess_?¶ ********
│ │ │ │ │ @@ -136,15 +136,15 @@
│ │ │ │ │ _B_a_s_e_C_o_m_m_a_n_d’s _s_u_b_c_l_a_s_s_e_s.
│ │ │ │ │ BaseCommand.help_¶
│ │ │ │ │ A short description of the command, which will be printed in the help
│ │ │ │ │ message when the user runs the command python manage.py help .
│ │ │ │ │ BaseCommand.missing_args_message_¶
│ │ │ │ │ If your command defines mandatory positional arguments, you can customize
│ │ │ │ │ the message error returned in the case of missing arguments. The default
│ │ │ │ │ - is output by _a_r_g_p_a_r_s_e (“too few arguments”).
│ │ │ │ │ + is output by _a_r_g_p_a_r_s_e («too few arguments»).
│ │ │ │ │ BaseCommand.output_transaction_¶
│ │ │ │ │ A boolean indicating whether the command outputs SQL statements; if True,
│ │ │ │ │ the output will automatically be wrapped with BEGIN; and COMMIT;. Default
│ │ │ │ │ value is False.
│ │ │ │ │ BaseCommand.requires_migrations_checks_¶
│ │ │ │ │ A boolean; if True, the command prints a warning if the set of migrations
│ │ │ │ │ on disk don’t match the migrations in the database. A warning doesn’t
│ │ │ │ │ @@ -155,15 +155,15 @@
│ │ │ │ │ executing the command. The value '__all__' can be used to specify that
│ │ │ │ │ all system checks should be performed. Default value is '__all__'.
│ │ │ │ │ BaseCommand.style_¶
│ │ │ │ │ An instance attribute that helps create colored output when writing to
│ │ │ │ │ stdout or stderr. For example:
│ │ │ │ │ self.stdout.write(self.style.SUCCESS("..."))
│ │ │ │ │ See _S_y_n_t_a_x_ _c_o_l_o_r_i_n_g to learn how to modify the color palette and to see
│ │ │ │ │ - the available styles (use uppercased versions of the “roles” described in
│ │ │ │ │ + the available styles (use uppercased versions of the «roles» described in
│ │ │ │ │ that section).
│ │ │ │ │ If you pass the _-_-_n_o_-_c_o_l_o_r option when running your command, all
│ │ │ │ │ self.style() calls will return the original string uncolored.
│ │ │ │ │ BaseCommand.suppressed_base_arguments_¶
│ │ │ │ │ The default command options to suppress in the help output. This should
│ │ │ │ │ be a set of option names (e.g. '--verbosity'). The default values for the
│ │ │ │ │ suppressed options are still passed.
│ │ │ │ │ @@ -173,42 +173,42 @@
│ │ │ │ │ Implementing a constructor in a subclass
│ │ │ │ │ If you implement __init__ in your subclass of _B_a_s_e_C_o_m_m_a_n_d, you must call
│ │ │ │ │ _B_a_s_e_C_o_m_m_a_n_d’s __init__:
│ │ │ │ │ class Command(BaseCommand):
│ │ │ │ │ def __init__(self, *args, **kwargs):
│ │ │ │ │ super().__init__(*args, **kwargs)
│ │ │ │ │ # ...
│ │ │ │ │ - BaseCommand.create_parser(pprroogg__nnaammee, ssuubbccoommmmaanndd, ****kkwwaarrggss)_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + BaseCommand.create_parser(pprroogg__nnaammee, ssuubbccoommmmaanndd, ****kkwwaarrggss)_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Returns a CommandParser instance, which is an _A_r_g_u_m_e_n_t_P_a_r_s_e_r subclass
│ │ │ │ │ with a few customizations for Django.
│ │ │ │ │ You can customize the instance by overriding this method and calling
│ │ │ │ │ super() with kwargs of _A_r_g_u_m_e_n_t_P_a_r_s_e_r parameters.
│ │ │ │ │ - BaseCommand.add_arguments(ppaarrsseerr)_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + BaseCommand.add_arguments(ppaarrsseerr)_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Entry point to add parser arguments to handle command line arguments
│ │ │ │ │ passed to the command. Custom commands should override this method to add
│ │ │ │ │ both positional and optional arguments accepted by the command. Calling
│ │ │ │ │ super() is not needed when directly subclassing BaseCommand.
│ │ │ │ │ - BaseCommand.get_version()_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + BaseCommand.get_version()_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Returns the Django version, which should be correct for all built-in
│ │ │ │ │ Django commands. User-supplied commands can override this method to
│ │ │ │ │ return their own version.
│ │ │ │ │ - BaseCommand.execute(**aarrggss, ****ooppttiioonnss)_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + BaseCommand.execute(**aarrggss, ****ooppttiioonnss)_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Tries to execute this command, performing system checks if needed (as
│ │ │ │ │ controlled by the _r_e_q_u_i_r_e_s___s_y_s_t_e_m___c_h_e_c_k_s attribute). If the command
│ │ │ │ │ raises a _C_o_m_m_a_n_d_E_r_r_o_r, it’s intercepted and printed to stderr.
│ │ │ │ │ Calling a management command in your code
│ │ │ │ │ execute() should not be called directly from your code to execute a command.
│ │ │ │ │ Use _c_a_l_l___c_o_m_m_a_n_d_(_) instead.
│ │ │ │ │ - BaseCommand.handle(**aarrggss, ****ooppttiioonnss)_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + BaseCommand.handle(**aarrggss, ****ooppttiioonnss)_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ The actual logic of the command. Subclasses must implement this method.
│ │ │ │ │ It may return a string which will be printed to stdout (wrapped by BEGIN;
│ │ │ │ │ and COMMIT; if _o_u_t_p_u_t___t_r_a_n_s_a_c_t_i_o_n is True).
│ │ │ │ │ BaseCommand.check(aapppp__ccoonnffiiggss==NNoonnee, ttaaggss==NNoonnee, ddiissppllaayy__nnuumm__eerrrroorrss==FFaallssee,
│ │ │ │ │ iinncclluuddee__ddeeppllooyymmeenntt__cchheecckkss==FFaallssee, ffaaiill__lleevveell==cchheecckkss..EERRRROORR, ddaattaabbaasseess==NNoonnee)
│ │ │ │ │ - _[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + _[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Uses the system check framework to inspect the entire Django project for
│ │ │ │ │ potential problems. Serious problems are raised as a _C_o_m_m_a_n_d_E_r_r_o_r;
│ │ │ │ │ warnings are output to stderr; minor notifications are output to stdout.
│ │ │ │ │ If app_configs and tags are both None, all system checks are performed
│ │ │ │ │ except deployment and database related checks. tags can be a list of
│ │ │ │ │ check tags, like compatibility or models.
│ │ │ │ │ You can pass include_deployment_checks=True to also perform deployment
│ │ │ │ │ @@ -232,15 +232,15 @@
│ │ │ │ │ A string describing the arbitrary arguments passed to the command. The
│ │ │ │ │ string is used in the usage text and error messages of the command.
│ │ │ │ │ Defaults to 'label'.
│ │ │ │ │ LabelCommand.handle_label(llaabbeell, ****ooppttiioonnss)_¶
│ │ │ │ │ Perform the command’s actions for label, which will be the string as
│ │ │ │ │ given on the command line.
│ │ │ │ │ ******** CCoommmmaanndd eexxcceeppttiioonnss_?¶ ********
│ │ │ │ │ - eexxcceeppttiioonn CommandError(rreettuurrnnccooddee==11)_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + eexxcceeppttiioonn CommandError(rreettuurrnnccooddee==11)_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Exception class indicating a problem while executing a management command.
│ │ │ │ │ If this exception is raised during the execution of a management command from a
│ │ │ │ │ command line console, it will be caught and turned into a nicely-printed error
│ │ │ │ │ message to the appropriate output stream (i.e., stderr); as a result, raising
│ │ │ │ │ this exception (with a sensible description of the error) is the preferred way
│ │ │ │ │ to indicate that something has gone wrong in the execution of a command. It
│ │ │ │ │ accepts the optional returncode argument to customize the exit status for the
│ │ │ │ │ @@ -254,16 +254,16 @@
│ │ │ │ │ o _T_e_s_t_i_n_g
│ │ │ │ │ o _O_v_e_r_r_i_d_i_n_g_ _c_o_m_m_a_n_d_s
│ │ │ │ │ o _C_o_m_m_a_n_d_ _o_b_j_e_c_t_s
│ │ │ │ │ # _A_t_t_r_i_b_u_t_e_s
│ │ │ │ │ # _M_e_t_h_o_d_s
│ │ │ │ │ # _B_a_s_e_C_o_m_m_a_n_d_ _s_u_b_c_l_a_s_s_e_s
│ │ │ │ │ # _C_o_m_m_a_n_d_ _e_x_c_e_p_t_i_o_n_s
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _H_o_w_ _t_o_ _u_s_e_ _D_j_a_n_g_o_’_s_ _C_S_R_F_ _p_r_o_t_e_c_t_i_o_n
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _H_o_w_ _t_o_ _c_r_e_a_t_e_ _c_u_s_t_o_m_ _m_o_d_e_l_ _f_i_e_l_d_s
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/howto/custom-model-fields.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - How to create custom model fields — Django 5.1b1 documentation
│ │ │ │ + How to create custom model fields — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,25 +54,25 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
We assign to and retrieve from the hand attribute in our model just like
│ │ │ │ any other Python class. The trick is to tell Django how to handle saving and
│ │ │ │ loading such an object.
│ │ │ │
In order to use the Hand class in our models, we do not have to change
│ │ │ │ this class at all. This is ideal, because it means you can easily write
│ │ │ │ model support for existing classes where you cannot change the source code.
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
You might only be wanting to take advantage of custom database column
│ │ │ │ types and deal with the data as standard Python types in your models;
│ │ │ │ strings, or floats, for example. This case is similar to our Hand
│ │ │ │ example and we’ll note any differences as we go along.
Our HandField accepts most of the standard field options (see the list
│ │ │ │ below), but we ensure it has a fixed length, since it only needs to hold 52
│ │ │ │ card values plus their suits; 104 characters in total.
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
Many of Django’s model fields accept options that they don’t do anything
│ │ │ │ with. For example, you can pass both
│ │ │ │ editable and
│ │ │ │ auto_now to a
│ │ │ │ django.db.models.DateField and it will ignore the
│ │ │ │ editable parameter
│ │ │ │ (auto_now being set implies
│ │ │ │ @@ -399,15 +400,15 @@
│ │ │ │
As always, you should document your field type, so users will know what it is.
│ │ │ │ In addition to providing a docstring for it, which is useful for developers,
│ │ │ │ you can also allow users of the admin app to see a short description of the
│ │ │ │ field type via the django.contrib.admindocs application. To do this provide descriptive
│ │ │ │ text in a description class attribute of your custom field. In
│ │ │ │ the above example, the description displayed by the admindocs application
│ │ │ │ -for a HandField will be ‘A hand of cards (bridge style)’.
│ │ │ │ +for a HandField will be “A hand of cards (bridge style)”.
│ │ │ │
In the django.contrib.admindocs display, the field description is
│ │ │ │ interpolated with field.__dict__ which allows the description to
│ │ │ │ incorporate arguments of the field. For example, the description for
│ │ │ │ CharField is:
│ │ │ │
description=_("String (up to %(max_length)s)")
│ │ │ │
If your custom field uses the CHAR, VARCHAR or TEXT
│ │ │ │ types for MySQL, you must make sure that get_prep_value()
│ │ │ │ always returns a string type. MySQL performs flexible and unexpected
│ │ │ │ matching when a query is performed on these types and the provided
│ │ │ │ value is an integer, which can cause queries to include unexpected
│ │ │ │ objects in their results. This problem cannot occur if you always
│ │ │ │ return a string type from get_prep_value().
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ HHooww ttoo ccrreeaattee ccuussttoomm mmooddeell ffiieellddss_?¶ ************
│ │ │ │ │ ********** IInnttrroodduuccttiioonn_?¶ **********
│ │ │ │ │ The _m_o_d_e_l_ _r_e_f_e_r_e_n_c_e documentation explains how to use Django’s standard field
│ │ │ │ │ classes – _C_h_a_r_F_i_e_l_d, _D_a_t_e_F_i_e_l_d, etc. For many purposes, those classes are all
│ │ │ │ │ you’ll need. Sometimes, though, the Django version won’t meet your precise
│ │ │ │ │ @@ -45,15 +45,15 @@
│ │ │ │ │ example.save()
│ │ │ │ │ We assign to and retrieve from the hand attribute in our model just like any
│ │ │ │ │ other Python class. The trick is to tell Django how to handle saving and
│ │ │ │ │ loading such an object.
│ │ │ │ │ In order to use the Hand class in our models, we ddoo nnoott have to change this
│ │ │ │ │ class at all. This is ideal, because it means you can easily write model
│ │ │ │ │ support for existing classes where you cannot change the source code.
│ │ │ │ │ -Note
│ │ │ │ │ +Nota
│ │ │ │ │ You might only be wanting to take advantage of custom database column types and
│ │ │ │ │ deal with the data as standard Python types in your models; strings, or floats,
│ │ │ │ │ for example. This case is similar to our Hand example and we’ll note any
│ │ │ │ │ differences as we go along.
│ │ │ │ │ ********** BBaacckkggrroouunndd tthheeoorryy_?¶ **********
│ │ │ │ │ ******** DDaattaabbaassee ssttoorraaggee_?¶ ********
│ │ │ │ │ Let’s start with model fields. If you break it down, a model field provides a
│ │ │ │ │ @@ -122,15 +122,15 @@
│ │ │ │ │
│ │ │ │ │ def __init__(self, *args, **kwargs):
│ │ │ │ │ kwargs["max_length"] = 104
│ │ │ │ │ super().__init__(*args, **kwargs)
│ │ │ │ │ Our HandField accepts most of the standard field options (see the list below),
│ │ │ │ │ but we ensure it has a fixed length, since it only needs to hold 52 card values
│ │ │ │ │ plus their suits; 104 characters in total.
│ │ │ │ │ -Note
│ │ │ │ │ +Nota
│ │ │ │ │ Many of Django’s model fields accept options that they don’t do anything with.
│ │ │ │ │ For example, you can pass both _e_d_i_t_a_b_l_e and _a_u_t_o___n_o_w to a
│ │ │ │ │ _d_j_a_n_g_o_._d_b_._m_o_d_e_l_s_._D_a_t_e_F_i_e_l_d and it will ignore the _e_d_i_t_a_b_l_e parameter (_a_u_t_o___n_o_w
│ │ │ │ │ being set implies editable=False). No error is raised in this case.
│ │ │ │ │ This behavior simplifies the field classes, because they don’t need to check
│ │ │ │ │ for options that aren’t necessary. They pass all the options to the parent
│ │ │ │ │ class and then don’t use them later on. It’s up to you whether you want your
│ │ │ │ │ @@ -261,15 +261,15 @@
│ │ │ │ │ ******** DDooccuummeennttiinngg yyoouurr ccuussttoomm ffiieelldd_?¶ ********
│ │ │ │ │ As always, you should document your field type, so users will know what it is.
│ │ │ │ │ In addition to providing a docstring for it, which is useful for developers,
│ │ │ │ │ you can also allow users of the admin app to see a short description of the
│ │ │ │ │ field type via the _d_j_a_n_g_o_._c_o_n_t_r_i_b_._a_d_m_i_n_d_o_c_s application. To do this provide
│ │ │ │ │ descriptive text in a _d_e_s_c_r_i_p_t_i_o_n class attribute of your custom field. In the
│ │ │ │ │ above example, the description displayed by the admindocs application for a
│ │ │ │ │ -HandField will be ‘A hand of cards (bridge style)’.
│ │ │ │ │ +HandField will be “A hand of cards (bridge style)”.
│ │ │ │ │ In the _d_j_a_n_g_o_._c_o_n_t_r_i_b_._a_d_m_i_n_d_o_c_s display, the field description is interpolated
│ │ │ │ │ with field.__dict__ which allows the description to incorporate arguments of
│ │ │ │ │ the field. For example, the description for _C_h_a_r_F_i_e_l_d is:
│ │ │ │ │ description = _("String (up to %(max_length)s)")
│ │ │ │ │ ******** UUsseeffuull mmeetthhooddss_?¶ ********
│ │ │ │ │ Once you’ve created your _F_i_e_l_d subclass, you might consider overriding a few
│ │ │ │ │ standard methods, depending on your field’s behavior. The list of methods below
│ │ │ │ │ @@ -417,15 +417,15 @@
│ │ │ │ │ # ...
│ │ │ │ │
│ │ │ │ │ def get_prep_value(self, value):
│ │ │ │ │ return "".join(
│ │ │ │ │ ["".join(l) for l in (value.north, value.east, value.south,
│ │ │ │ │ value.west)]
│ │ │ │ │ )
│ │ │ │ │ -Warning
│ │ │ │ │ +Avvertimento
│ │ │ │ │ If your custom field uses the CHAR, VARCHAR or TEXT types for MySQL, you must
│ │ │ │ │ make sure that _g_e_t___p_r_e_p___v_a_l_u_e_(_) always returns a string type. MySQL performs
│ │ │ │ │ flexible and unexpected matching when a query is performed on these types and
│ │ │ │ │ the provided value is an integer, which can cause queries to include unexpected
│ │ │ │ │ objects in their results. This problem cannot occur if you always return a
│ │ │ │ │ string type from _g_e_t___p_r_e_p___v_a_l_u_e_(_).
│ │ │ │ │ ****** CCoonnvveerrttiinngg qquueerryy vvaalluueess ttoo ddaattaabbaassee vvaalluueess_?¶ ******
│ │ │ │ │ @@ -569,16 +569,16 @@
│ │ │ │ │ # _P_r_e_p_r_o_c_e_s_s_i_n_g_ _v_a_l_u_e_s_ _b_e_f_o_r_e_ _s_a_v_i_n_g
│ │ │ │ │ # _S_p_e_c_i_f_y_i_n_g_ _t_h_e_ _f_o_r_m_ _f_i_e_l_d_ _f_o_r_ _a_ _m_o_d_e_l_ _f_i_e_l_d
│ │ │ │ │ # _E_m_u_l_a_t_i_n_g_ _b_u_i_l_t_-_i_n_ _f_i_e_l_d_ _t_y_p_e_s
│ │ │ │ │ # _C_o_n_v_e_r_t_i_n_g_ _f_i_e_l_d_ _d_a_t_a_ _f_o_r_ _s_e_r_i_a_l_i_z_a_t_i_o_n
│ │ │ │ │ # _S_o_m_e_ _g_e_n_e_r_a_l_ _a_d_v_i_c_e
│ │ │ │ │ o _W_r_i_t_i_n_g_ _a_ _F_i_l_e_F_i_e_l_d_ _s_u_b_c_l_a_s_s
│ │ │ │ │ # _A_ _f_e_w_ _s_u_g_g_e_s_t_i_o_n_s
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _H_o_w_ _t_o_ _c_r_e_a_t_e_ _c_u_s_t_o_m_ _d_j_a_n_g_o_-_a_d_m_i_n_ _c_o_m_m_a_n_d_s
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _H_o_w_ _t_o_ _w_r_i_t_e_ _c_u_s_t_o_m_ _l_o_o_k_u_p_s
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/howto/custom-template-backend.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - How to implement a custom template backend — Django 5.1b1 documentation
│ │ │ │ + How to implement a custom template backend — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,25 +54,25 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -279,19 +280,19 @@
│ │ │ │ handling for you. All you need to do is set the is_safe flag to True
│ │ │ │ when you register your filter function, like so:
│ │ │ │
This flag tells Django that if a “safe” string is passed into your
│ │ │ │ -filter, the result will still be “safe” and if a non-safe string is
│ │ │ │ +
This flag tells Django that if a «safe» string is passed into your
│ │ │ │ +filter, the result will still be «safe» and if a non-safe string is
│ │ │ │ passed in, Django will automatically escape it, if necessary.
│ │ │ │ -
You can think of this as meaning “this filter is safe – it doesn’t
│ │ │ │ -introduce any possibility of unsafe HTML.”
│ │ │ │ +
You can think of this as meaning «this filter is safe – it doesn’t
│ │ │ │ +introduce any possibility of unsafe HTML.»
│ │ │ │
The reason is_safe is necessary is because there are plenty of
│ │ │ │ normal string operations that will turn a SafeData object back into
│ │ │ │ a normal str object and, rather than try to catch them all, which would
│ │ │ │ be very difficult, Django repairs the damage after the filter has completed.
│ │ │ │
For example, suppose you have a filter that adds the string xx to
│ │ │ │ the end of any input. Since this introduces no dangerous HTML characters
│ │ │ │ to the result (aside from any that were already present), you should
│ │ │ │ @@ -299,15 +300,15 @@
│ │ │ │
When this filter is used in a template where auto-escaping is enabled,
│ │ │ │ Django will escape the output whenever the input is not already marked
│ │ │ │ -as “safe”.
│ │ │ │ +as «safe».
│ │ │ │
By default, is_safe is False, and you can omit it from any filters
│ │ │ │ where it isn’t required.
│ │ │ │
Be careful when deciding if your filter really does leave safe strings
│ │ │ │ as safe. If you’re removing characters, you might inadvertently leave
│ │ │ │ unbalanced HTML tags or entities in the result. For example, removing a
│ │ │ │ > from the input might turn <a> into <a, which would need to
│ │ │ │ be escaped on output to avoid causing problems. Similarly, removing a
│ │ │ │ @@ -315,15 +316,15 @@
│ │ │ │ valid entity and thus needs further escaping. Most cases won’t be nearly
│ │ │ │ this tricky, but keep an eye out for any problems like that when
│ │ │ │ reviewing your code.
│ │ │ │
Marking a filter is_safe will coerce the filter’s return value to
│ │ │ │ a string. If your filter should return a boolean or other non-string
│ │ │ │ value, marking it is_safe will probably have unintended
│ │ │ │ consequences (such as converting a boolean False to the string
│ │ │ │ -‘False’).
│ │ │ │ +“False”).
│ │ │ │
│ │ │ │
Alternatively, your filter code can manually take care of any necessary
│ │ │ │ escaping. This is necessary when you’re introducing new HTML markup into
│ │ │ │ the result. You want to mark the output as safe from further
│ │ │ │ escaping so that your HTML markup isn’t escaped further, so you’ll need
│ │ │ │ to handle the input yourself.
│ │ │ │
To mark the output as a safe string, use
│ │ │ │ @@ -361,30 +362,30 @@
│ │ │ │ returnmark_safe(result)
│ │ │ │
│ │ │ │
│ │ │ │
The needs_autoescape flag and the autoescape keyword argument mean
│ │ │ │ that our function will know whether automatic escaping is in effect when the
│ │ │ │ filter is called. We use autoescape to decide whether the input data
│ │ │ │ needs to be passed through django.utils.html.conditional_escape or not.
│ │ │ │ -(In the latter case, we use the identity function as the “escape” function.)
│ │ │ │ +(In the latter case, we use the identity function as the «escape» function.)
│ │ │ │ The conditional_escape() function is like escape() except it only
│ │ │ │ escapes input that is not a SafeData instance. If a SafeData
│ │ │ │ instance is passed to conditional_escape(), the data is returned
│ │ │ │ unchanged.
│ │ │ │
Finally, in the above example, we remember to mark the result as safe
│ │ │ │ so that our HTML is inserted directly into the template without further
│ │ │ │ escaping.
│ │ │ │
There’s no need to worry about the is_safe flag in this case
│ │ │ │ (although including it wouldn’t hurt anything). Whenever you manually
│ │ │ │ handle the auto-escaping issues and return a safe string, the
│ │ │ │ is_safe flag won’t change anything either way.
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ -
Warning
│ │ │ │ +
Avvertimento
│ │ │ │
Avoiding XSS vulnerabilities when reusing built-in filters
│ │ │ │
Django’s built-in filters have autoescape=True by default in order to
│ │ │ │ get the proper autoescaping behavior and avoid a cross-site script
│ │ │ │ vulnerability.
│ │ │ │
In older versions of Django, be careful when reusing Django’s built-in
│ │ │ │ filters as autoescape defaults to None. You’ll need to pass
│ │ │ │ autoescape=True to get autoescaping.
Then in the template any number of arguments, separated by spaces, may be
│ │ │ │ passed to the template tag. Like in Python, the values for keyword arguments
│ │ │ │ -are set using the equal sign (”=”) and must be provided after the
│ │ │ │ +are set using the equal sign (»=») and must be provided after the
│ │ │ │ positional arguments. For example:
It’s possible to store the tag results in a template variable rather than
│ │ │ │ directly outputting it. This is done by using the as argument followed by
│ │ │ │ the variable name. Doing so enables you to output the content yourself where
│ │ │ │ @@ -532,20 +533,20 @@
│ │ │ │
Another common type of template tag is the type that displays some data by
│ │ │ │ rendering another template. For example, Django’s admin interface uses custom
│ │ │ │ -template tags to display the buttons along the bottom of the “add/change” form
│ │ │ │ +template tags to display the buttons along the bottom of the «add/change» form
│ │ │ │ pages. Those buttons always look the same, but the link targets change
│ │ │ │ depending on the object being edited – so they’re a perfect case for using a
│ │ │ │ small template that is filled with details from the current object. (In the
│ │ │ │ admin’s case, this is the submit_row tag.)
│ │ │ │ -
These sorts of tags are called “inclusion tags”.
│ │ │ │ +
These sorts of tags are called «inclusion tags».
│ │ │ │
Writing inclusion tags is probably best demonstrated by example. Let’s write a
│ │ │ │ tag that outputs a list of choices for a given Poll object, such as was
│ │ │ │ created in the tutorials. We’ll use the tag like this:
Then in the template any number of arguments, separated by spaces, may be
│ │ │ │ passed to the template tag. Like in Python, the values for keyword arguments
│ │ │ │ -are set using the equal sign (”=”) and must be provided after the
│ │ │ │ +are set using the equal sign (»=») and must be provided after the
│ │ │ │ positional arguments. For example:
The template system works in a two-step process: compiling and rendering. To
│ │ │ │ define a custom template tag, you specify how the compilation works and how
│ │ │ │ the rendering works.
│ │ │ │
When Django compiles a template, it splits the raw template text into
│ │ │ │ -‘’nodes’’. Each node is an instance of django.template.Node and has
│ │ │ │ +“”nodes””. Each node is an instance of django.template.Node and has
│ │ │ │ a render() method. A compiled template is a list of Node objects. When
│ │ │ │ you call render() on a compiled template object, the template calls
│ │ │ │ render() on each Node in its node list, with the given context. The
│ │ │ │ results are all concatenated together to form the output of the template.
│ │ │ │
Thus, to define a custom template tag, you specify how the raw template tag is
│ │ │ │ converted into a Node (the compilation function), and what the node’s
│ │ │ │ render() method does.
│ │ │ │ @@ -712,15 +713,15 @@
│ │ │ │ idea to always use token.split_contents().
│ │ │ │
This function is responsible for raising
│ │ │ │ django.template.TemplateSyntaxError, with helpful messages, for
│ │ │ │ any syntax error.
│ │ │ │
The TemplateSyntaxError exceptions use the tag_name variable.
│ │ │ │ Don’t hard-code the tag’s name in your error messages, because that
│ │ │ │ couples the tag’s name to your function. token.contents.split()[0]
│ │ │ │ -will ‘’always’’ be the name of your tag – even when the tag has no
│ │ │ │ +will “”always”” be the name of your tag – even when the tag has no
│ │ │ │ arguments.
│ │ │ │
The function returns a CurrentTimeNode with everything the node needs
│ │ │ │ to know about this tag. In this case, it passes the argument –
│ │ │ │ "%Y-%m-%d%I:%M%p". The leading and trailing quotes from the
│ │ │ │ template tag are removed in format_string[1:-1].
│ │ │ │
The parsing is very low-level. The Django developers have experimented
│ │ │ │ with writing small frameworks on top of this parsing system, using
│ │ │ │ @@ -831,21 +832,21 @@
│ │ │ │ returnnext(self.cycle_iter)
│ │ │ │
│ │ │ │
│ │ │ │
But, suppose we have two templates rendering the template snippet from above at
│ │ │ │ the same time:
│ │ │ │
│ │ │ │
Thread 1 performs its first loop iteration, CycleNode.render()
│ │ │ │ -returns ‘row1’
│ │ │ │ +returns “row1”
│ │ │ │
Thread 2 performs its first loop iteration, CycleNode.render()
│ │ │ │ -returns ‘row2’
│ │ │ │ +returns “row2”
│ │ │ │
Thread 1 performs its second loop iteration, CycleNode.render()
│ │ │ │ -returns ‘row1’
│ │ │ │ +returns “row1”
│ │ │ │
Thread 2 performs its second loop iteration, CycleNode.render()
│ │ │ │ -returns ‘row2’
│ │ │ │ +returns “row2”
│ │ │ │
│ │ │ │
The CycleNode is iterating, but it’s iterating globally. As far as Thread 1
│ │ │ │ and Thread 2 are concerned, it’s always returning the same value. This is
│ │ │ │ not what we want!
│ │ │ │
To address this problem, Django provides a render_context that’s associated
│ │ │ │ with the context of the template that is currently being rendered. The
│ │ │ │ render_context behaves like a Python dictionary, and should be used to
│ │ │ │ @@ -866,15 +867,15 @@
│ │ │ │ throughout the life of the Node as an attribute. In the case of
│ │ │ │ CycleNode, the cyclevars argument doesn’t change after the Node is
│ │ │ │ instantiated, so we don’t need to put it in the render_context. But state
│ │ │ │ information that is specific to the template that is currently being rendered,
│ │ │ │ like the current iteration of the CycleNode, should be stored in the
│ │ │ │ render_context.
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
Notice how we used self to scope the CycleNode specific information
│ │ │ │ within the render_context. There may be multiple CycleNodes in a
│ │ │ │ given template, so we need to be careful not to clobber another node’s
│ │ │ │ state information. The easiest way to do this is to always use self as
│ │ │ │ the key into render_context. If you’re keeping track of several state
│ │ │ │ variables, make render_context[self] a dictionary.
The actual implementation of {%comment%} is slightly
│ │ │ │ different in that it allows broken template tags to appear between
│ │ │ │ {%comment%} and {%endcomment%}. It does so by calling
│ │ │ │ parser.skip_past('endcomment') instead of parser.parse(('endcomment',))
│ │ │ │ followed by parser.delete_first_token(), thus avoiding the generation of a
│ │ │ │ node list.
│ │ │ │
│ │ │ │ -
parser.parse() takes a tuple of names of block tags ‘’to parse until’’. It
│ │ │ │ +
parser.parse() takes a tuple of names of block tags “”to parse until””. It
│ │ │ │ returns an instance of django.template.NodeList, which is a list of
│ │ │ │ -all Node objects that the parser encountered ‘’before’’ it encountered
│ │ │ │ +all Node objects that the parser encountered “”before”” it encountered
│ │ │ │ any of the tags named in the tuple.
│ │ │ │
In "nodelist=parser.parse(('endcomment',))" in the above example,
│ │ │ │ nodelist is a list of all nodes between the {%comment%} and
│ │ │ │ {%endcomment%}, not counting {%comment%} and {%endcomment%}
│ │ │ │ themselves.
│ │ │ │ -
After parser.parse() is called, the parser hasn’t yet “consumed” the
│ │ │ │ +
After parser.parse() is called, the parser hasn’t yet «consumed» the
│ │ │ │ {%endcomment%} tag, so the code needs to explicitly call
│ │ │ │ parser.delete_first_token().
│ │ │ │
CommentNode.render() returns an empty string. Anything between
│ │ │ │ {%comment%} and {%endcomment%} is ignored.
│ │ │ │
│ │ │ │
│ │ │ │
Parsing until another block tag, and saving contents¶
Remove all references to the app (imports, foreign keys etc.).
│ │ │ │
Remove all models from the corresponding models.py file.
│ │ │ │
Create relevant migrations by running makemigrations. This step
│ │ │ │ generates a migration that deletes tables for the removed models, and any
│ │ │ │ other required migration for updating relationships connected to those
│ │ │ │ models.
│ │ │ │ -
Squash out references to the app in other apps’
│ │ │ │ +
Squash out references to the app in other apps”
│ │ │ │ migrations.
│ │ │ │
Apply migrations locally, runs tests, and verify the correctness of your
│ │ │ │ project.
The startproject command creates a file
│ │ │ │ <project_name>/asgi.py that contains such an application callable.
│ │ │ │
It’s not used by the development server (runserver), but can be used by
│ │ │ │ any ASGI server either in development or in production.
│ │ │ │
ASGI servers usually take the path to the application callable as a string;
│ │ │ │ for most Django projects, this will look like myproject.asgi:application.
│ │ │ │
│ │ │ │ -
Warning
│ │ │ │ +
Avvertimento
│ │ │ │
While Django’s default ASGI handler will run all your code in a synchronous
│ │ │ │ thread, if you choose to run your own async handler you must be aware of
│ │ │ │ async-safety.
│ │ │ │
Do not call blocking synchronous functions or libraries in any async code.
│ │ │ │ Django prevents you from doing this with the parts of Django that are not
│ │ │ │ async-safe, but the same may not be true of third-party apps or Python
│ │ │ │ libraries.
│ │ │ │ @@ -161,15 +162,15 @@
│ │ │ │ header, or otherwise ensure that you aren’t vulnerable to this category of
│ │ │ │ attacks.
│ │ │ │
You should also configure the web server that sits in front of Django to
│ │ │ │ validate the host. It should respond with a static error page or ignore
│ │ │ │ requests for incorrect hosts instead of forwarding the request to Django. This
│ │ │ │ way you’ll avoid spurious errors in your Django logs (or emails if you have
│ │ │ │ error reporting configured that way). For example, on nginx you might set up a
│ │ │ │ -default server to return “444 No Response” on an unrecognized host:
│ │ │ │ +default server to return «444 No Response» on an unrecognized host:
│ │ │ │
Django is full of shortcuts to make web developers’ lives easier, but all
│ │ │ │ +
Django is full of shortcuts to make web developers” lives easier, but all
│ │ │ │ those tools are of no use if you can’t easily deploy your sites. Since Django’s
│ │ │ │ inception, ease of deployment has been a major goal.
│ │ │ │
There are many options for deploying your Django application, based on your
│ │ │ │ architecture or your particular business needs, but that discussion is outside
│ │ │ │ the scope of what Django can give you as guidance.
│ │ │ │
Django, being a web framework, needs a web server in order to operate. And
│ │ │ │ since most web servers don’t natively speak Python, we need an interface to
│ │ │ │ @@ -142,47 +143,47 @@
│ │ │ │
│ │ │ │
│ │ │ │
Serve static/media files directly from Apache only to authenticated users.
│ │ │ │
Authenticate access to a Subversion repository against Django users with
│ │ │ │ a certain permission.
│ │ │ │
Allow certain users to connect to a WebDAV share created with mod_dav.
│ │ │ │
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
If you have installed a custom user model and
│ │ │ │ want to use this default auth handler, it must support an is_active
│ │ │ │ attribute. If you want to use group based authorization, your custom user
│ │ │ │ -must have a relation named ‘groups’, referring to a related object that has
│ │ │ │ -a ‘name’ field. You can also specify your own custom mod_wsgi
│ │ │ │ +must have a relation named “groups”, referring to a related object that has
│ │ │ │ +a “name” field. You can also specify your own custom mod_wsgi
│ │ │ │ auth handler if your custom cannot conform to these requirements.
The use of WSGIApplicationGroup%{GLOBAL} in the configurations below
│ │ │ │ presumes that your Apache instance is running only one Django application.
│ │ │ │ If you are running more than one Django application, please refer to the
│ │ │ │ Defining Application Groups section of the mod_wsgi docs for more
│ │ │ │ information about this setting.
│ │ │ │
│ │ │ │
Make sure that mod_wsgi is installed and activated and that you have
│ │ │ │ @@ -183,15 +184,15 @@
│ │ │ │
To support the WSGIAuthGroupScript directive, the same WSGI script
│ │ │ │ mysite.wsgi must also import the groups_for_user function which
│ │ │ │ returns a list groups the given user belongs to.
│ │ │ │ @@ -117,15 +118,15 @@
│ │ │ │ locate the appropriate settings module. It must contain the dotted path to the
│ │ │ │ settings module. You can use a different value for development and production;
│ │ │ │ it all depends on how you organize your settings.
│ │ │ │
If this variable isn’t set, the default wsgi.py sets it to
│ │ │ │ mysite.settings, where mysite is the name of your project. That’s how
│ │ │ │ runserver discovers the default settings file by default.
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
Since environment variables are process-wide, this doesn’t work when you
│ │ │ │ run multiple Django sites in the same process. This happens with mod_wsgi.
│ │ │ │
To avoid this problem, use mod_wsgi’s daemon mode with each site in its
│ │ │ │ own daemon process, or override the value from the environment by
│ │ │ │ enforcing os.environ["DJANGO_SETTINGS_MODULE"]="mysite.settings" in
│ │ │ │ your wsgi.py.
The first bit in the WSGIScriptAlias line is the base URL path you want to
│ │ │ │ serve your application at (/ indicates the root url), and the second is the
│ │ │ │ -location of a “WSGI file” – see below – on your system, usually inside of
│ │ │ │ +location of a «WSGI file» – see below – on your system, usually inside of
│ │ │ │ your project package (mysite in this example). This tells Apache to serve
│ │ │ │ any request below the given URL using the WSGI application defined in that
│ │ │ │ file.
The WSGIPythonPath line ensures that your project package is available for
│ │ │ │ @@ -117,15 +118,15 @@
│ │ │ │ file.
│ │ │ │
Next we’ll need to ensure this wsgi.py with a WSGI application object
│ │ │ │ exists. As of Django version 1.4, startproject will have created one
│ │ │ │ for you; otherwise, you’ll need to create it. See the WSGI overview
│ │ │ │ documentation for the default contents you
│ │ │ │ should put in this file, and what else you can add to it.
│ │ │ │
│ │ │ │ -
Warning
│ │ │ │ +
Avvertimento
│ │ │ │
If multiple Django sites are run in a single mod_wsgi process, all of them
│ │ │ │ will use the settings of whichever one happens to run first. This can be
│ │ │ │ solved by changing:
“Daemon mode” is the recommended mode for running mod_wsgi (on non-Windows
│ │ │ │ +
«Daemon mode» is the recommended mode for running mod_wsgi (on non-Windows
│ │ │ │ platforms). To create the required daemon process group and delegate the
│ │ │ │ Django instance to run in it, you will need to add appropriate
│ │ │ │ WSGIDaemonProcess and WSGIProcessGroup directives. A further change
│ │ │ │ required to the above configuration if you use daemon mode is that you can’t
│ │ │ │ use WSGIPythonPath; instead you should use the python-path option to
│ │ │ │ WSGIDaemonProcess, for example:
uWSGI is a fast, self-healing and developer/sysadmin-friendly application
│ │ │ │ container server coded in pure C.
│ │ │ │
│ │ │ │ -
See also
│ │ │ │ +
Vedi anche
│ │ │ │
The uWSGI docs offer a tutorial covering Django, nginx, and uWSGI (one
│ │ │ │ possible deployment setup of many). The docs below are focused on how to
│ │ │ │ integrate Django with uWSGI.
uWSGI operates on a client-server model. Your web server (e.g., nginx, Apache)
│ │ │ │ -communicates with a django-uwsgi “worker” process to serve dynamic content.
│ │ │ │ +communicates with a django-uwsgi «worker» process to serve dynamic content.
│ │ │ │
│ │ │ │
│ │ │ │
Configuring and starting the uWSGI server for Django¶
│ │ │ │ @@ -95,15 +96,15 @@
│ │ │ │ ADMINS setting whenever your code raises an unhandled exception and
│ │ │ │ results in an internal server error (strictly speaking, for any response with
│ │ │ │ an HTTP status code of 500 or greater). This gives the administrators immediate
│ │ │ │ notification of any errors. The ADMINS will get a description of the
│ │ │ │ error, a complete Python traceback, and details about the HTTP request that
│ │ │ │ caused the error.
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
In order to send email, Django requires a few settings telling it
│ │ │ │ how to connect to your mail server. At the very least, you’ll need
│ │ │ │ to specify EMAIL_HOST and possibly
│ │ │ │ EMAIL_HOST_USER and EMAIL_HOST_PASSWORD,
│ │ │ │ though other settings may be also required depending on your mail
│ │ │ │ server’s configuration. Consult the Django settings
│ │ │ │ documentation for a full list of email-related
│ │ │ │ @@ -111,36 +112,36 @@
│ │ │ │
│ │ │ │
By default, Django will send email from root@localhost. However, some mail
│ │ │ │ providers reject all email from this address. To use a different sender
│ │ │ │ address, modify the SERVER_EMAIL setting.
│ │ │ │
To activate this behavior, put the email addresses of the recipients in the
│ │ │ │ ADMINS setting.
If those conditions are met, Django will email the users listed in the
│ │ │ │ MANAGERS setting whenever your code raises a 404 and the request has
│ │ │ │ a referer. It doesn’t bother to email for 404s that don’t have a referer –
│ │ │ │ those are usually people typing in broken URLs or broken web bots. It also
│ │ │ │ ignores 404s when the referer is equal to the requested URL, since this
│ │ │ │ behavior is from broken web bots too.
You can tell Django to stop reporting particular 404s by tweaking the
│ │ │ │ @@ -170,25 +171,25 @@
│ │ │ │
(Note that these are regular expressions, so we put a backslash in front of
│ │ │ │ periods to escape them.)
│ │ │ │
If you’d like to customize the behavior of
│ │ │ │ django.middleware.common.BrokenLinkEmailsMiddleware further (for
│ │ │ │ example to ignore requests coming from web crawlers), you should subclass it
│ │ │ │ and override its methods.
│ │ │ │
│ │ │ │ -
See also
│ │ │ │ +
Vedi anche
│ │ │ │
404 errors are logged using the logging framework. By default, these log
│ │ │ │ records are ignored, but you can use them for error reporting by writing a
│ │ │ │ handler and configuring logging appropriately.
Filtering sensitive data is a hard problem, and it’s nearly impossible to
│ │ │ │ guarantee that sensitive data won’t leak into an error report. Therefore,
│ │ │ │ error reports should only be available to trusted team members and you
│ │ │ │ should avoid transmitting error reports unencrypted over the internet
│ │ │ │ (such as through email).
│ │ │ │
│ │ │ │
│ │ │ │ @@ -204,15 +205,15 @@
│ │ │ │ sensitive as described in the DEBUG documentation, Django offers a
│ │ │ │ set of function decorators to help you control which information should be
│ │ │ │ filtered out of error reports in a production environment (that is, where
│ │ │ │ DEBUG is set to False): sensitive_variables() and
│ │ │ │ sensitive_post_parameters().
│ │ │ │
If a function (either a view or any regular callback) in your code uses
│ │ │ │ local variables susceptible to contain sensitive information, you may
│ │ │ │ prevent the values of those variables from being included in error reports
│ │ │ │ using the sensitive_variables decorator:
If the variable you want to hide is also a function argument (e.g.
│ │ │ │ -‘user’ in the following example), and if the decorated function has
│ │ │ │ +“user’ in the following example), and if the decorated function has
│ │ │ │ multiple decorators, then make sure to place @sensitive_variables
│ │ │ │ at the top of the decorator chain. This way it will also hide the
│ │ │ │ function argument as it gets passed through the other decorators:
If one of your views receives an HttpRequest object
│ │ │ │ with POSTparameters susceptible to
│ │ │ │ contain sensitive information, you may prevent the values of those
│ │ │ │ parameters from being included in the error reports using the
│ │ │ │ sensitive_post_parameters decorator:
All sensitive_variables() and sensitive_post_parameters() do is,
│ │ │ │ respectively, annotate the decorated function with the names of sensitive
│ │ │ │ variables and annotate the HttpRequest object with the names of sensitive
│ │ │ │ POST parameters, so that this sensitive information can later be filtered out
│ │ │ │ of reports when an error occurs. The actual filtering is done by Django’s
│ │ │ │ default error reporter filter:
│ │ │ │ django.views.debug.SafeExceptionReporterFilter. This filter uses the
│ │ │ │ -decorators’ annotations to replace the corresponding values with stars
│ │ │ │ +decorators” annotations to replace the corresponding values with stars
│ │ │ │ (**********) when the error reports are produced. If you wish to
│ │ │ │ override or customize this default behavior for your entire site, you need to
│ │ │ │ define your own filter class and tell Django to use it via the
│ │ │ │ DEFAULT_EXCEPTION_REPORTER_FILTER setting:
Returns True to activate the filtering in
│ │ │ │ get_post_parameters() and get_traceback_frame_variables().
│ │ │ │ By default the filter is active if DEBUG is False. Note
│ │ │ │ that sensitive request.META values are always filtered along with
│ │ │ │ sensitive setting values, as described in the DEBUG
│ │ │ │ documentation.
Returns the filtered dictionary of local variables for the given
│ │ │ │ traceback frame. Sensitive values are replaced with
│ │ │ │ cleansed_substitute.
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -388,35 +389,35 @@
│ │ │ │ and formatting it as text or HTML appropriately. (The exception reporter uses
│ │ │ │ DEFAULT_EXCEPTION_REPORTER_FILTER when preparing the exception
│ │ │ │ report data.)
│ │ │ │
Property that returns a pathlib.Path representing the absolute
│ │ │ │ filesystem path to a template for rendering the HTML representation of
│ │ │ │ the exception. Defaults to the Django provided template.
Property that returns a pathlib.Path representing the absolute
│ │ │ │ filesystem path to a template for rendering the plain-text
│ │ │ │ representation of the exception. Defaults to the Django provided
│ │ │ │ template.
You can also set up custom error reporting by writing a custom piece of
│ │ │ │ exception middleware. If you do write custom
│ │ │ │ error handling, it’s a good idea to emulate Django’s built-in error handling
│ │ │ │ and only report/log errors if DEBUG is False.
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ HHooww ttoo mmaannaaggee eerrrroorr rreeppoorrttiinngg_?¶ ************
│ │ │ │ │ When you’re running a public site you should always turn off the _D_E_B_U_G setting.
│ │ │ │ │ That will make your server run much faster, and will also prevent malicious
│ │ │ │ │ users from seeing details of your application that can be revealed by the error
│ │ │ │ │ pages.
│ │ │ │ │ @@ -14,42 +14,42 @@
│ │ │ │ │ ******** SSeerrvveerr eerrrroorrss_?¶ ********
│ │ │ │ │ When _D_E_B_U_G is False, Django will email the users listed in the _A_D_M_I_N_S setting
│ │ │ │ │ whenever your code raises an unhandled exception and results in an internal
│ │ │ │ │ server error (strictly speaking, for any response with an HTTP status code of
│ │ │ │ │ 500 or greater). This gives the administrators immediate notification of any
│ │ │ │ │ errors. The _A_D_M_I_N_S will get a description of the error, a complete Python
│ │ │ │ │ traceback, and details about the HTTP request that caused the error.
│ │ │ │ │ -Note
│ │ │ │ │ +Nota
│ │ │ │ │ In order to send email, Django requires a few settings telling it how to
│ │ │ │ │ connect to your mail server. At the very least, you’ll need to specify
│ │ │ │ │ _E_M_A_I_L___H_O_S_T and possibly _E_M_A_I_L___H_O_S_T___U_S_E_R and _E_M_A_I_L___H_O_S_T___P_A_S_S_W_O_R_D, though other
│ │ │ │ │ settings may be also required depending on your mail server’s configuration.
│ │ │ │ │ Consult _t_h_e_ _D_j_a_n_g_o_ _s_e_t_t_i_n_g_s_ _d_o_c_u_m_e_n_t_a_t_i_o_n for a full list of email-related
│ │ │ │ │ settings.
│ │ │ │ │ By default, Django will send email from _r_o_o_t_@_l_o_c_a_l_h_o_s_t. However, some mail
│ │ │ │ │ providers reject all email from this address. To use a different sender
│ │ │ │ │ address, modify the _S_E_R_V_E_R___E_M_A_I_L setting.
│ │ │ │ │ To activate this behavior, put the email addresses of the recipients in the
│ │ │ │ │ _A_D_M_I_N_S setting.
│ │ │ │ │ -See also
│ │ │ │ │ +Vedi anche
│ │ │ │ │ Server error emails are sent using the logging framework, so you can customize
│ │ │ │ │ this behavior by _c_u_s_t_o_m_i_z_i_n_g_ _y_o_u_r_ _l_o_g_g_i_n_g_ _c_o_n_f_i_g_u_r_a_t_i_o_n.
│ │ │ │ │ ******** 440044 eerrrroorrss_?¶ ********
│ │ │ │ │ -Django can also be configured to email errors about broken links (404 “page not
│ │ │ │ │ -found” errors). Django sends emails about 404 errors when:
│ │ │ │ │ +Django can also be configured to email errors about broken links (404 «page not
│ │ │ │ │ +found» errors). Django sends emails about 404 errors when:
│ │ │ │ │ * _D_E_B_U_G is False;
│ │ │ │ │ * Your _M_I_D_D_L_E_W_A_R_E setting includes
│ │ │ │ │ _d_j_a_n_g_o_._m_i_d_d_l_e_w_a_r_e_._c_o_m_m_o_n_._B_r_o_k_e_n_L_i_n_k_E_m_a_i_l_s_M_i_d_d_l_e_w_a_r_e.
│ │ │ │ │ If those conditions are met, Django will email the users listed in the _M_A_N_A_G_E_R_S
│ │ │ │ │ setting whenever your code raises a 404 and the request has a referer. It
│ │ │ │ │ doesn’t bother to email for 404s that don’t have a referer – those are usually
│ │ │ │ │ people typing in broken URLs or broken web bots. It also ignores 404s when the
│ │ │ │ │ referer is equal to the requested URL, since this behavior is from broken web
│ │ │ │ │ bots too.
│ │ │ │ │ -Note
│ │ │ │ │ +Nota
│ │ │ │ │ _B_r_o_k_e_n_L_i_n_k_E_m_a_i_l_s_M_i_d_d_l_e_w_a_r_e must appear before other middleware that intercepts
│ │ │ │ │ 404 errors, such as _L_o_c_a_l_e_M_i_d_d_l_e_w_a_r_e or _F_l_a_t_p_a_g_e_F_a_l_l_b_a_c_k_M_i_d_d_l_e_w_a_r_e. Put it
│ │ │ │ │ toward the top of your _M_I_D_D_L_E_W_A_R_E setting.
│ │ │ │ │ You can tell Django to stop reporting particular 404s by tweaking the
│ │ │ │ │ _I_G_N_O_R_A_B_L_E___4_0_4___U_R_L_S setting. It should be a list of compiled regular expression
│ │ │ │ │ objects. For example:
│ │ │ │ │ import re
│ │ │ │ │ @@ -71,20 +71,20 @@
│ │ │ │ │ ]
│ │ │ │ │ (Note that these are regular expressions, so we put a backslash in front of
│ │ │ │ │ periods to escape them.)
│ │ │ │ │ If you’d like to customize the behavior of
│ │ │ │ │ _d_j_a_n_g_o_._m_i_d_d_l_e_w_a_r_e_._c_o_m_m_o_n_._B_r_o_k_e_n_L_i_n_k_E_m_a_i_l_s_M_i_d_d_l_e_w_a_r_e further (for example to
│ │ │ │ │ ignore requests coming from web crawlers), you should subclass it and override
│ │ │ │ │ its methods.
│ │ │ │ │ -See also
│ │ │ │ │ +Vedi anche
│ │ │ │ │ 404 errors are logged using the logging framework. By default, these log
│ │ │ │ │ records are ignored, but you can use them for error reporting by writing a
│ │ │ │ │ handler and _c_o_n_f_i_g_u_r_i_n_g_ _l_o_g_g_i_n_g appropriately.
│ │ │ │ │ ********** FFiilltteerriinngg eerrrroorr rreeppoorrttss_?¶ **********
│ │ │ │ │ -Warning
│ │ │ │ │ +Avvertimento
│ │ │ │ │ Filtering sensitive data is a hard problem, and it’s nearly impossible to
│ │ │ │ │ guarantee that sensitive data won’t leak into an error report. Therefore, error
│ │ │ │ │ reports should only be available to trusted team members and you should avoid
│ │ │ │ │ transmitting error reports unencrypted over the internet (such as through
│ │ │ │ │ email).
│ │ │ │ │ ******** FFiilltteerriinngg sseennssiittiivvee iinnffoorrmmaattiioonn_?¶ ********
│ │ │ │ │ Error reports are really helpful for debugging errors, so it is generally
│ │ │ │ │ @@ -95,15 +95,15 @@
│ │ │ │ │ However, sometimes certain types of information may be too sensitive and thus
│ │ │ │ │ may not be appropriate to be kept track of, for example a user’s password or
│ │ │ │ │ credit card number. So in addition to filtering out settings that appear to be
│ │ │ │ │ sensitive as described in the _D_E_B_U_G documentation, Django offers a set of
│ │ │ │ │ function decorators to help you control which information should be filtered
│ │ │ │ │ out of error reports in a production environment (that is, where _D_E_B_U_G is set
│ │ │ │ │ to False): _s_e_n_s_i_t_i_v_e___v_a_r_i_a_b_l_e_s_(_) and _s_e_n_s_i_t_i_v_e___p_o_s_t___p_a_r_a_m_e_t_e_r_s_(_).
│ │ │ │ │ - sensitive_variables(**vvaarriiaabblleess)_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + sensitive_variables(**vvaarriiaabblleess)_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ If a function (either a view or any regular callback) in your code uses
│ │ │ │ │ local variables susceptible to contain sensitive information, you may
│ │ │ │ │ prevent the values of those variables from being included in error
│ │ │ │ │ reports using the sensitive_variables decorator:
│ │ │ │ │ from django.views.decorators.debug import sensitive_variables
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ @@ -117,26 +117,26 @@
│ │ │ │ │ be hidden and replaced with stars (**********) in the error reports,
│ │ │ │ │ whereas the value of the name variable will be disclosed.
│ │ │ │ │ To systematically hide all local variables of a function from error logs,
│ │ │ │ │ do not provide any argument to the sensitive_variables decorator:
│ │ │ │ │ @sensitive_variables()
│ │ │ │ │ def my_function(): ...
│ │ │ │ │ When using multiple decorators
│ │ │ │ │ - If the variable you want to hide is also a function argument (e.g. ‘user’
│ │ │ │ │ + If the variable you want to hide is also a function argument (e.g. “user’
│ │ │ │ │ in the following example), and if the decorated function has multiple
│ │ │ │ │ decorators, then make sure to place @sensitive_variables at the top of
│ │ │ │ │ the decorator chain. This way it will also hide the function argument as
│ │ │ │ │ it gets passed through the other decorators:
│ │ │ │ │ @sensitive_variables("user", "pw", "cc")
│ │ │ │ │ @some_decorator
│ │ │ │ │ @another_decorator
│ │ │ │ │ def process_info(user): ...
│ │ │ │ │ Changed in Django 5.0:
│ │ │ │ │ Support for wrapping async functions was added.
│ │ │ │ │ - sensitive_post_parameters(**ppaarraammeetteerrss)_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + sensitive_post_parameters(**ppaarraammeetteerrss)_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ If one of your views receives an _H_t_t_p_R_e_q_u_e_s_t object with _P_O_S_T_ _p_a_r_a_m_e_t_e_r_s
│ │ │ │ │ susceptible to contain sensitive information, you may prevent the values
│ │ │ │ │ of those parameters from being included in the error reports using the
│ │ │ │ │ sensitive_post_parameters decorator:
│ │ │ │ │ from django.views.decorators.debug import sensitive_post_parameters
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ @@ -166,15 +166,15 @@
│ │ │ │ │ ******** CCuussttoomm eerrrroorr rreeppoorrttss_?¶ ********
│ │ │ │ │ All _s_e_n_s_i_t_i_v_e___v_a_r_i_a_b_l_e_s_(_) and _s_e_n_s_i_t_i_v_e___p_o_s_t___p_a_r_a_m_e_t_e_r_s_(_) do is, respectively,
│ │ │ │ │ annotate the decorated function with the names of sensitive variables and
│ │ │ │ │ annotate the HttpRequest object with the names of sensitive POST parameters, so
│ │ │ │ │ that this sensitive information can later be filtered out of reports when an
│ │ │ │ │ error occurs. The actual filtering is done by Django’s default error reporter
│ │ │ │ │ filter: _d_j_a_n_g_o_._v_i_e_w_s_._d_e_b_u_g_._S_a_f_e_E_x_c_e_p_t_i_o_n_R_e_p_o_r_t_e_r_F_i_l_t_e_r. This filter uses the
│ │ │ │ │ -decorators’ annotations to replace the corresponding values with stars
│ │ │ │ │ +decorators” annotations to replace the corresponding values with stars
│ │ │ │ │ (**********) when the error reports are produced. If you wish to override or
│ │ │ │ │ customize this default behavior for your entire site, you need to define your
│ │ │ │ │ own filter class and tell Django to use it via the
│ │ │ │ │ _D_E_F_A_U_L_T___E_X_C_E_P_T_I_O_N___R_E_P_O_R_T_E_R___F_I_L_T_E_R setting:
│ │ │ │ │ DEFAULT_EXCEPTION_REPORTER_FILTER =
│ │ │ │ │ "path.to.your.CustomExceptionReporterFilter"
│ │ │ │ │ You may also control in a more granular way which filter to use within any
│ │ │ │ │ @@ -182,98 +182,98 @@
│ │ │ │ │ def my_view(request):
│ │ │ │ │ if request.user.is_authenticated:
│ │ │ │ │ request.exception_reporter_filter = CustomExceptionReporterFilter()
│ │ │ │ │ ...
│ │ │ │ │ Your custom filter class needs to inherit from
│ │ │ │ │ _d_j_a_n_g_o_._v_i_e_w_s_._d_e_b_u_g_._S_a_f_e_E_x_c_e_p_t_i_o_n_R_e_p_o_r_t_e_r_F_i_l_t_e_r and may override the following
│ │ │ │ │ attributes and methods:
│ │ │ │ │ - ccllaassss SafeExceptionReporterFilter_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + ccllaassss SafeExceptionReporterFilter_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ cleansed_substitute_¶
│ │ │ │ │ The string value to replace sensitive value with. By default it
│ │ │ │ │ replaces the values of sensitive variables with stars (**********).
│ │ │ │ │ hidden_settings_¶
│ │ │ │ │ A compiled regular expression object used to match settings and
│ │ │ │ │ request.META values considered as sensitive. By default equivalent
│ │ │ │ │ to:
│ │ │ │ │ import re
│ │ │ │ │
│ │ │ │ │ re.compile(r"API|TOKEN|KEY|SECRET|PASS|SIGNATURE|HTTP_COOKIE",
│ │ │ │ │ flags=re.IGNORECASE)
│ │ │ │ │ - is_active(rreeqquueesstt)_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + is_active(rreeqquueesstt)_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Returns True to activate the filtering in _g_e_t___p_o_s_t___p_a_r_a_m_e_t_e_r_s_(_) and
│ │ │ │ │ _g_e_t___t_r_a_c_e_b_a_c_k___f_r_a_m_e___v_a_r_i_a_b_l_e_s_(_). By default the filter is active if
│ │ │ │ │ _D_E_B_U_G is False. Note that sensitive request.META values are always
│ │ │ │ │ filtered along with sensitive setting values, as described in the
│ │ │ │ │ _D_E_B_U_G documentation.
│ │ │ │ │ - get_post_parameters(rreeqquueesstt)_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + get_post_parameters(rreeqquueesstt)_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Returns the filtered dictionary of POST parameters. Sensitive
│ │ │ │ │ values are replaced with _c_l_e_a_n_s_e_d___s_u_b_s_t_i_t_u_t_e.
│ │ │ │ │ - get_traceback_frame_variables(rreeqquueesstt, ttbb__ffrraammee)_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + get_traceback_frame_variables(rreeqquueesstt, ttbb__ffrraammee)_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Returns the filtered dictionary of local variables for the given
│ │ │ │ │ traceback frame. Sensitive values are replaced with
│ │ │ │ │ _c_l_e_a_n_s_e_d___s_u_b_s_t_i_t_u_t_e.
│ │ │ │ │ If you need to customize error reports beyond filtering you may specify a
│ │ │ │ │ custom error reporter class by defining the _D_E_F_A_U_L_T___E_X_C_E_P_T_I_O_N___R_E_P_O_R_T_E_R setting:
│ │ │ │ │ DEFAULT_EXCEPTION_REPORTER = "path.to.your.CustomExceptionReporter"
│ │ │ │ │ The exception reporter is responsible for compiling the exception report data,
│ │ │ │ │ and formatting it as text or HTML appropriately. (The exception reporter uses
│ │ │ │ │ _D_E_F_A_U_L_T___E_X_C_E_P_T_I_O_N___R_E_P_O_R_T_E_R___F_I_L_T_E_R when preparing the exception report data.)
│ │ │ │ │ Your custom reporter class needs to inherit from
│ │ │ │ │ _d_j_a_n_g_o_._v_i_e_w_s_._d_e_b_u_g_._E_x_c_e_p_t_i_o_n_R_e_p_o_r_t_e_r.
│ │ │ │ │ - ccllaassss ExceptionReporter_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ - html_template_path_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + ccllaassss ExceptionReporter_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ + html_template_path_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Property that returns a _p_a_t_h_l_i_b_._P_a_t_h representing the absolute
│ │ │ │ │ filesystem path to a template for rendering the HTML representation
│ │ │ │ │ of the exception. Defaults to the Django provided template.
│ │ │ │ │ - text_template_path_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + text_template_path_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Property that returns a _p_a_t_h_l_i_b_._P_a_t_h representing the absolute
│ │ │ │ │ filesystem path to a template for rendering the plain-text
│ │ │ │ │ representation of the exception. Defaults to the Django provided
│ │ │ │ │ template.
│ │ │ │ │ - get_traceback_data()_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + get_traceback_data()_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Return a dictionary containing traceback information.
│ │ │ │ │ This is the main extension point for customizing exception reports,
│ │ │ │ │ for example:
│ │ │ │ │ from django.views.debug import ExceptionReporter
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ class CustomExceptionReporter(ExceptionReporter):
│ │ │ │ │ def get_traceback_data(self):
│ │ │ │ │ data = super().get_traceback_data()
│ │ │ │ │ # ... remove/add something here ...
│ │ │ │ │ return data
│ │ │ │ │ - get_traceback_html()_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + get_traceback_html()_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Return HTML version of exception report.
│ │ │ │ │ Used for HTML version of debug 500 HTTP error page.
│ │ │ │ │ - get_traceback_text()_[_s_o_u_r_c_e_]_¶
│ │ │ │ │ + get_traceback_text()_[_s_o_r_g_e_n_t_e_]_¶
│ │ │ │ │ Return plain text version of exception report.
│ │ │ │ │ Used for plain text version of debug 500 HTTP error page and email
│ │ │ │ │ reports.
│ │ │ │ │ As with the filter class, you may control which exception reporter class to use
│ │ │ │ │ within any given view by setting the HttpRequest’s exception_reporter_class
│ │ │ │ │ attribute:
│ │ │ │ │ def my_view(request):
│ │ │ │ │ if request.user.is_authenticated:
│ │ │ │ │ request.exception_reporter_class = CustomExceptionReporter()
│ │ │ │ │ ...
│ │ │ │ │ -See also
│ │ │ │ │ +Vedi anche
│ │ │ │ │ You can also set up custom error reporting by writing a custom piece of
│ │ │ │ │ _e_x_c_e_p_t_i_o_n_ _m_i_d_d_l_e_w_a_r_e. If you do write custom error handling, it’s a good idea
│ │ │ │ │ to emulate Django’s built-in error handling and only report/log errors if _D_E_B_U_G
│ │ │ │ │ is False.
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ * _H_o_w_ _t_o_ _m_a_n_a_g_e_ _e_r_r_o_r_ _r_e_p_o_r_t_i_n_g
│ │ │ │ │ o _E_m_a_i_l_ _r_e_p_o_r_t_s
│ │ │ │ │ # _S_e_r_v_e_r_ _e_r_r_o_r_s
│ │ │ │ │ # _4_0_4_ _e_r_r_o_r_s
│ │ │ │ │ o _F_i_l_t_e_r_i_n_g_ _e_r_r_o_r_ _r_e_p_o_r_t_s
│ │ │ │ │ # _F_i_l_t_e_r_i_n_g_ _s_e_n_s_i_t_i_v_e_ _i_n_f_o_r_m_a_t_i_o_n
│ │ │ │ │ # _C_u_s_t_o_m_ _e_r_r_o_r_ _r_e_p_o_r_t_s
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _H_o_w_ _t_o_ _u_p_g_r_a_d_e_ _D_j_a_n_g_o_ _t_o_ _a_ _n_e_w_e_r_ _v_e_r_s_i_o_n
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _H_o_w_ _t_o_ _p_r_o_v_i_d_e_ _i_n_i_t_i_a_l_ _d_a_t_a_ _f_o_r_ _m_o_d_e_l_s
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/howto/index.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - “How-to” guides — Django 5.1b1 documentation
│ │ │ │ + «How-to» guides — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,37 +54,37 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Here you’ll find short answers to «How do I….?» types of questions. These
│ │ │ │ how-to guides don’t cover topics in depth – you’ll find that material in the
│ │ │ │ Using Django and the API Reference. However, these guides will help
│ │ │ │ you quickly accomplish common tasks.
The Django community aggregator, where we aggregate content from the
│ │ │ │ global Django community. Many writers in the aggregator write this sort of
│ │ │ │ how-to material.
│ │ │ │ @@ -159,15 +160,15 @@
│ │ │ │ you have fixture files with the same name in different applications, you
│ │ │ │ will be unable to distinguish between them in your loaddata commands.
│ │ │ │ The easiest way to avoid this problem is by namespacing your fixture
│ │ │ │ files. That is, by putting them inside a directory named for their
│ │ │ │ application, as in the relative path example above.
│ │ │ │
│ │ │ │
│ │ │ │ -
See also
│ │ │ │ +
Vedi anche
│ │ │ │
Fixtures are also used by the testing framework to help set up a consistent test environment.
The WARNING level used in the example above is one of several
│ │ │ │ logging severity levels: DEBUG,
│ │ │ │ INFO, WARNING, ERROR, CRITICAL. So, another example might be:
│ │ │ │
logger.critical("Payment system is not responding")
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ -
Important
│ │ │ │ +
Importante
│ │ │ │
Records with a level lower than WARNING will not appear in the console
│ │ │ │ by default. Changing this behavior requires additional configuration.
The response gets a special MIME type, text/csv. This tells
│ │ │ │ browsers that the document is a CSV file, rather than an HTML file. If
│ │ │ │ you leave this off, browsers will probably interpret the output as HTML,
│ │ │ │ which will result in ugly, scary gobbledygook in the browser window.
│ │ │ │
The response gets an additional Content-Disposition header, which
│ │ │ │ contains the name of the CSV file. This filename is arbitrary; call it
│ │ │ │ -whatever you want. It’ll be used by browsers in the “Save as…” dialog, etc.
│ │ │ │ +whatever you want. It’ll be used by browsers in the «Save as…» dialog, etc.
│ │ │ │
You can hook into the CSV-generation API by passing response as the first
│ │ │ │ argument to csv.writer. The csv.writer function expects a file-like
│ │ │ │ object, and HttpResponse objects fit the bill.
│ │ │ │
For each row in your CSV file, call writer.writerow, passing it an
│ │ │ │ iterable.
│ │ │ │
The CSV module takes care of quoting for you, so you don’t have to worry
│ │ │ │ about escaping strings with quotes or commas in them. Pass writerow()
│ │ │ │ @@ -241,47 +242,47 @@
│ │ │ │
The key to generating PDFs dynamically with Django is that the ReportLab API
│ │ │ │ acts on file-like objects, and Django’s FileResponse
│ │ │ │ objects accept file-like objects.
When as_attachment=True is passed to FileResponse, it sets the
│ │ │ │ appropriate Content-Disposition header and that tells web browsers to
│ │ │ │ pop-up a dialog box prompting/confirming how to handle the document even if a
│ │ │ │ default is set on the machine. If the as_attachment parameter is omitted,
│ │ │ │ browsers will handle the PDF using whatever program/plugin they’ve been
│ │ │ │ configured to use for PDFs.
│ │ │ │
You can provide an arbitrary filename parameter. It’ll be used by browsers
│ │ │ │ -in the “Save as…” dialog.
│ │ │ │ +in the «Save as…» dialog.
│ │ │ │
You can hook into the ReportLab API: The same buffer passed as the first
│ │ │ │ argument to canvas.Canvas can be fed to the
│ │ │ │ FileResponse class.
│ │ │ │
Note that all subsequent PDF-generation methods are called on the PDF
│ │ │ │ object (in this case, p) – not on buffer.
│ │ │ │
Finally, it’s important to call showPage() and save() on the PDF
│ │ │ │ file.
│ │ │ │
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
ReportLab is not thread-safe. Some of our users have reported odd issues
│ │ │ │ with building PDF-generating Django views that are accessed by many people
│ │ │ │ at the same time.
Notice that there isn’t a lot in these examples that’s PDF-specific – just the
│ │ │ │ bits using reportlab. You can use a similar technique to generate any
│ │ │ │ arbitrary format that you can find a Python library for. Also see
│ │ │ │ How to create CSV output for another example and some techniques you can use
│ │ │ │ when generated text-based formats.
│ │ │ │
│ │ │ │ -
See also
│ │ │ │ +
Vedi anche
│ │ │ │
Django Packages provides a comparison of packages that help generate PDF files
│ │ │ │ from Django.
│ │ │ │ @@ -84,15 +85,15 @@
│ │ │ │ such as django.contrib.admin. You can either put template overrides in your
│ │ │ │ project’s templates directory or in an application’s templates directory.
│ │ │ │
If you have app and project templates directories that both contain overrides,
│ │ │ │ the default Django template loader will try to load the template from the
│ │ │ │ project-level directory first. In other words, DIRS
│ │ │ │ is searched before APP_DIRS.
The basic outline of putting static files into production consists of two
│ │ │ │ steps: run the collectstatic command when static files change, then
│ │ │ │ @@ -195,47 +196,47 @@
│ │ │ │
How to manage static files (e.g. images, JavaScript, CSS)¶
│ │ │ │
Websites generally need to serve additional files such as images, JavaScript,
│ │ │ │ -or CSS. In Django, we refer to these files as “static files”. Django provides
│ │ │ │ +or CSS. In Django, we refer to these files as «static files». Django provides
│ │ │ │ django.contrib.staticfiles to help you manage them.
│ │ │ │
This page describes how you can serve these static files.
Make sure that django.contrib.staticfiles is included in your
│ │ │ │ INSTALLED_APPS.
│ │ │ │ @@ -159,15 +160,15 @@
│ │ │ │
│ │ │ │ urlpatterns=[
│ │ │ │ # ... the rest of your URLconf goes here ...
│ │ │ │ ]+static(settings.STATIC_URL,document_root=settings.STATIC_ROOT)
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
This helper function works only in debug mode and only if
│ │ │ │ the given prefix is local (e.g. static/) and not a URL (e.g.
│ │ │ │ http://static.example.com/).
│ │ │ │
Also this helper function only serves the actual STATIC_ROOT
│ │ │ │ folder; it doesn’t perform static files discovery like
│ │ │ │ django.contrib.staticfiles.
│ │ │ │
Finally, static files are served via a wrapper at the WSGI application
│ │ │ │ @@ -188,15 +189,15 @@
│ │ │ │
│ │ │ │ urlpatterns=[
│ │ │ │ # ... the rest of your URLconf goes here ...
│ │ │ │ ]+static(settings.MEDIA_URL,document_root=settings.MEDIA_ROOT)
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
This helper function works only in debug mode and only if
│ │ │ │ the given prefix is local (e.g. media/) and not a URL (e.g.
│ │ │ │ http://media.example.com/).
Afterward, you should familiarize yourself with the changes that were made in
│ │ │ │ the new Django version(s):
│ │ │ │
│ │ │ │ -
Read the release notes for each ‘final’ release from
│ │ │ │ +
Read the release notes for each “final” release from
│ │ │ │ the one after your current Django version, up to and including the version to
│ │ │ │ which you plan to upgrade.
Django is a Python web framework, thus requiring Python to be installed on your
│ │ │ │ machine. At the time of writing, Python 3.12 is the latest version.
│ │ │ │
To install Python on your machine go to https://www.python.org/downloads/. The
│ │ │ │ website should offer you a download button for the latest Python version.
│ │ │ │ -Download the executable installer and run it. Check the boxes next to “Install
│ │ │ │ -launcher for all users (recommended)” then click “Install Now”.
│ │ │ │ +Download the executable installer and run it. Check the boxes next to «Install
│ │ │ │ +launcher for all users (recommended)» then click «Install Now».
│ │ │ │
After installation, open the command prompt and check that the Python version
│ │ │ │ matches the version you installed by executing:
pip is a package manager for Python and is included by default with the
│ │ │ │ Python installer. It helps to install and uninstall Python packages
│ │ │ │ @@ -122,20 +123,20 @@
│ │ │ │ environments which we will use for this guide.
│ │ │ │
To create a virtual environment for your project, open a new command prompt,
│ │ │ │ navigate to the folder where you want to create your project and then enter the
│ │ │ │ following:
│ │ │ │
...\> py -m venv project-name
│ │ │ │
│ │ │ │
│ │ │ │ -
This will create a folder called ‘project-name’ if it does not already exist
│ │ │ │ +
This will create a folder called “project-name” if it does not already exist
│ │ │ │ and set up the virtual environment. To activate the environment, run:
│ │ │ │
...\> project-name\Scripts\activate.bat
│ │ │ │
│ │ │ │
│ │ │ │ -
The virtual environment will be activated and you’ll see “(project-name)” next
│ │ │ │ +
The virtual environment will be activated and you’ll see «(project-name)» next
│ │ │ │ to the command prompt to designate that. Each time you start a new command
│ │ │ │ prompt, you’ll need to activate the environment again.
If your RunPython or RunSQL operation only affects one model, it’s good
│ │ │ │ practice to pass model_name as a hint to make it as transparent as possible
│ │ │ │ to the router. This is especially important for reusable and third-party apps.
Applying a “plain” migration that adds a unique non-nullable field to a table
│ │ │ │ +
Applying a «plain» migration that adds a unique non-nullable field to a table
│ │ │ │ with existing rows will raise an error because the value used to populate
│ │ │ │ existing rows is generated only once, thus breaking the unique constraint.
│ │ │ │
Therefore, the following steps should be taken. In this example, we’ll add a
│ │ │ │ non-nullable UUIDField with a default value. Modify
│ │ │ │ the respective field according to your needs.
│ │ │ │
│ │ │ │
Add the field on your model with default=uuid.uuid4 and unique=True
│ │ │ │ @@ -311,15 +312,15 @@
│ │ │ │ dependencies=[
│ │ │ │ ("myapp","0123_the_previous_migration"),
│ │ │ │ ]
│ │ │ │
│ │ │ │
│ │ │ │
Usually this will be enough, but from time to time you may need to
│ │ │ │ ensure that your migration runs before other migrations. This is
│ │ │ │ -useful, for example, to make third-party apps’ migrations run after
│ │ │ │ +useful, for example, to make third-party apps” migrations run after
│ │ │ │ your AUTH_USER_MODEL replacement.
│ │ │ │
To achieve this, place all migrations that should depend on yours in
│ │ │ │ the run_before attribute on your Migration class:
Django has a lot of documentation. A high-level overview of how it’s organized
│ │ │ │ will help you know where to look for certain things:
│ │ │ │
│ │ │ │
Tutorials take you by the hand through a series of
│ │ │ │ steps to create a web application. Start here if you’re new to Django or web
│ │ │ │ -application development. Also look at the “First steps”.
│ │ │ │ +application development. Also look at the «First steps».
│ │ │ │
Topic guides discuss key topics and concepts at a
│ │ │ │ fairly high level and provide useful background information and explanation.
│ │ │ │
Reference guides contain technical reference for APIs and
│ │ │ │ other aspects of Django’s machinery. They describe how it works and how to
│ │ │ │ use it but assume that you have a basic understanding of key concepts.
│ │ │ │
How-to guides are recipes. They guide you through the
│ │ │ │ steps involved in addressing key problems and use-cases. They are more
│ │ │ │ advanced than tutorials and assume some knowledge of how Django works.
Django provides an abstraction layer (the “models”) for structuring and
│ │ │ │ +
Django provides an abstraction layer (the «models») for structuring and
│ │ │ │ manipulating the data of your web application. Learn more about it below:
Django has the concept of “views” to encapsulate the logic responsible for
│ │ │ │ +
Django has the concept of «views» to encapsulate the logic responsible for
│ │ │ │ processing a user’s request and for returning the response. Find all you need
│ │ │ │ to know about views via the links below:
Please report security issues only to
│ │ │ │ security@djangoproject.com. This is a private list only open to
│ │ │ │ long-time, highly trusted Django developers, and its archives are
│ │ │ │ not public. For further details, please see our security
│ │ │ │ policies.
│ │ │ │
│ │ │ │
Otherwise, before reporting a bug or requesting a new feature on the
│ │ │ │ ticket tracker, consider these points:
│ │ │ │
│ │ │ │
Check that someone hasn’t already filed the bug or feature request by
│ │ │ │ searching or running custom queries in the ticket tracker.
│ │ │ │
Don’t use the ticket system to ask support questions. Use the
│ │ │ │ django-users list or the #django IRC channel for that.
│ │ │ │ -
Don’t reopen issues that have been marked “wontfix” without finding consensus
│ │ │ │ +
Don’t reopen issues that have been marked «wontfix» without finding consensus
│ │ │ │ to do so on the Django Forum or django-developers list.
│ │ │ │
Don’t use the ticket tracker for lengthy discussions, because they’re
│ │ │ │ likely to get lost. If a particular ticket is controversial, please move the
│ │ │ │ discussion to the Django Forum or django-developers list.
Whenever possible, we strive for a rough consensus. To that end, we’ll often
│ │ │ │ have informal votes on django-developers or the Django Forum about a feature.
│ │ │ │ In these votes we follow the voting style invented by Apache and used on Python
│ │ │ │ itself, where votes are given as +1, +0, -0, or -1.
│ │ │ │ Roughly translated, these votes mean:
│ │ │ │
│ │ │ │ -
+1: “I love the idea and I’m strongly committed to it.”
│ │ │ │ -
+0: “Sounds OK to me.”
│ │ │ │ -
-0: “I’m not thrilled, but I won’t stand in the way.”
│ │ │ │ -
-1: “I strongly disagree and would be very unhappy to see the idea turn
│ │ │ │ -into reality.”
│ │ │ │ +
+1: «I love the idea and I’m strongly committed to it.»
│ │ │ │ +
+0: «Sounds OK to me.»
│ │ │ │ +
-0: «I’m not thrilled, but I won’t stand in the way.»
│ │ │ │ +
-1: «I strongly disagree and would be very unhappy to see the idea turn
│ │ │ │ +into reality.»
│ │ │ │
│ │ │ │
Although these votes are informal, they’ll be taken very seriously. After a
│ │ │ │ suitable voting period, if an obvious consensus arises we’ll follow the votes.
│ │ │ │
However, consensus is not always possible. If consensus cannot be reached, or
│ │ │ │ if the discussion toward a consensus fizzles out without a concrete decision,
│ │ │ │ the decision may be deferred to the steering council.
│ │ │ │
Internally, the steering council will use the same voting mechanism. A
│ │ │ │ proposition will be considered carried if:
│ │ │ │
│ │ │ │ -
There are at least three “+1” votes from members of the steering council.
│ │ │ │ -
There is no “-1” vote from any member of the steering council.
│ │ │ │ +
There are at least three «+1» votes from members of the steering council.
│ │ │ │ +
There is no «-1» vote from any member of the steering council.
│ │ │ │
│ │ │ │
Votes should be submitted within a week.
│ │ │ │
Since this process allows any steering council member to veto a proposal, a
│ │ │ │ -“-1” vote should be accompanied by an explanation of what it would take to
│ │ │ │ -convert that “-1” into at least a “+0”.
│ │ │ │ +«-1» vote should be accompanied by an explanation of what it would take to
│ │ │ │ +convert that «-1» into at least a «+0».
│ │ │ │
Votes on technical matters should be announced and held in public on the
│ │ │ │ django-developers mailing list or on the Django Forum.
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,22 +1,22 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ RReeppoorrttiinngg bbuuggss aanndd rreeqquueessttiinngg ffeeaattuurreess_?¶ ************
│ │ │ │ │ -Important
│ │ │ │ │ +Importante
│ │ │ │ │ Please report security issues oonnllyy to _s_e_c_u_r_i_t_y_@_d_j_a_n_g_o_p_r_o_j_e_c_t_._c_o_m. This is a
│ │ │ │ │ private list only open to long-time, highly trusted Django developers, and its
│ │ │ │ │ archives are not public. For further details, please see _o_u_r_ _s_e_c_u_r_i_t_y_ _p_o_l_i_c_i_e_s.
│ │ │ │ │ Otherwise, before reporting a bug or requesting a new feature on the _t_i_c_k_e_t
│ │ │ │ │ _t_r_a_c_k_e_r, consider these points:
│ │ │ │ │ * Check that someone hasn’t already filed the bug or feature request by
│ │ │ │ │ _s_e_a_r_c_h_i_n_g or running _c_u_s_t_o_m_ _q_u_e_r_i_e_s in the ticket tracker.
│ │ │ │ │ * Don’t use the ticket system to ask support questions. Use the _d_j_a_n_g_o_-
│ │ │ │ │ _u_s_e_r_s list or the _#_d_j_a_n_g_o IRC channel for that.
│ │ │ │ │ - * Don’t reopen issues that have been marked “wontfix” without finding
│ │ │ │ │ + * Don’t reopen issues that have been marked «wontfix» without finding
│ │ │ │ │ consensus to do so on the _D_j_a_n_g_o_ _F_o_r_u_m or _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s list.
│ │ │ │ │ * Don’t use the ticket tracker for lengthy discussions, because they’re
│ │ │ │ │ likely to get lost. If a particular ticket is controversial, please move
│ │ │ │ │ the discussion to the _D_j_a_n_g_o_ _F_o_r_u_m or _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s list.
│ │ │ │ │ ********** RReeppoorrttiinngg bbuuggss_?¶ **********
│ │ │ │ │ Well-written bug reports are iinnccrreeddiibbllyy helpful. However, there’s a certain
│ │ │ │ │ amount of overhead involved in working with any bug tracking system so your
│ │ │ │ │ @@ -82,42 +82,42 @@
│ │ │ │ │ See also: _D_o_c_u_m_e_n_t_i_n_g_ _n_e_w_ _f_e_a_t_u_r_e_s.
│ │ │ │ │ ********** HHooww wwee mmaakkee ddeecciissiioonnss_?¶ **********
│ │ │ │ │ Whenever possible, we strive for a rough consensus. To that end, we’ll often
│ │ │ │ │ have informal votes on _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s or the Django Forum about a feature.
│ │ │ │ │ In these votes we follow the voting style invented by Apache and used on Python
│ │ │ │ │ itself, where votes are given as +1, +0, -0, or -1. Roughly translated, these
│ │ │ │ │ votes mean:
│ │ │ │ │ - * +1: “I love the idea and I’m strongly committed to it.”
│ │ │ │ │ - * +0: “Sounds OK to me.”
│ │ │ │ │ - * -0: “I’m not thrilled, but I won’t stand in the way.”
│ │ │ │ │ - * -1: “I strongly disagree and would be very unhappy to see the idea turn
│ │ │ │ │ - into reality.”
│ │ │ │ │ + * +1: «I love the idea and I’m strongly committed to it.»
│ │ │ │ │ + * +0: «Sounds OK to me.»
│ │ │ │ │ + * -0: «I’m not thrilled, but I won’t stand in the way.»
│ │ │ │ │ + * -1: «I strongly disagree and would be very unhappy to see the idea turn
│ │ │ │ │ + into reality.»
│ │ │ │ │ Although these votes are informal, they’ll be taken very seriously. After a
│ │ │ │ │ suitable voting period, if an obvious consensus arises we’ll follow the votes.
│ │ │ │ │ However, consensus is not always possible. If consensus cannot be reached, or
│ │ │ │ │ if the discussion toward a consensus fizzles out without a concrete decision,
│ │ │ │ │ the decision may be deferred to the _s_t_e_e_r_i_n_g_ _c_o_u_n_c_i_l.
│ │ │ │ │ Internally, the steering council will use the same voting mechanism. A
│ │ │ │ │ proposition will be considered carried if:
│ │ │ │ │ - * There are at least three “+1” votes from members of the steering council.
│ │ │ │ │ - * There is no “-1” vote from any member of the steering council.
│ │ │ │ │ + * There are at least three «+1» votes from members of the steering council.
│ │ │ │ │ + * There is no «-1» vote from any member of the steering council.
│ │ │ │ │ Votes should be submitted within a week.
│ │ │ │ │ -Since this process allows any steering council member to veto a proposal, a “-
│ │ │ │ │ -1” vote should be accompanied by an explanation of what it would take to
│ │ │ │ │ -convert that “-1” into at least a “+0”.
│ │ │ │ │ +Since this process allows any steering council member to veto a proposal, a «-
│ │ │ │ │ +1» vote should be accompanied by an explanation of what it would take to
│ │ │ │ │ +convert that «-1» into at least a «+0».
│ │ │ │ │ Votes on technical matters should be announced and held in public on the
│ │ │ │ │ _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s mailing list or on the _D_j_a_n_g_o_ _F_o_r_u_m.
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ * _R_e_p_o_r_t_i_n_g_ _b_u_g_s_ _a_n_d_ _r_e_q_u_e_s_t_i_n_g_ _f_e_a_t_u_r_e_s
│ │ │ │ │ o _R_e_p_o_r_t_i_n_g_ _b_u_g_s
│ │ │ │ │ o _R_e_p_o_r_t_i_n_g_ _u_s_e_r_ _i_n_t_e_r_f_a_c_e_ _b_u_g_s_ _a_n_d_ _f_e_a_t_u_r_e_s
│ │ │ │ │ o _R_e_q_u_e_s_t_i_n_g_ _f_e_a_t_u_r_e_s
│ │ │ │ │ o _H_o_w_ _w_e_ _m_a_k_e_ _d_e_c_i_s_i_o_n_s
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _L_o_c_a_l_i_z_i_n_g_ _D_j_a_n_g_o
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _T_r_i_a_g_i_n_g_ _t_i_c_k_e_t_s
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/internals/contributing/committing-code.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Committing code — Django 5.1b1 documentation
│ │ │ │ + Committing code — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -66,15 +67,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Force push to the branch after rebasing on main but before merging and pushing
│ │ │ │ to upstream. This allows the commit hashes on main and the branch to match
│ │ │ │ which automatically closes the pull request.
│ │ │ │
If a pull request doesn’t need to be merged as multiple commits, you can use
│ │ │ │ -GitHub’s “Squash and merge” button on the website. Edit the commit message as
│ │ │ │ +GitHub’s «Squash and merge» button on the website. Edit the commit message as
│ │ │ │ needed to conform to the guidelines and remove
│ │ │ │ the pull request number that’s automatically appended to the message’s first
│ │ │ │ line.
│ │ │ │
When rewriting the commit history of a pull request, the goal is to make
│ │ │ │ Django’s commit history as usable as possible:
│ │ │ │
│ │ │ │
If a patch contains back-and-forth commits, then rewrite those into one.
│ │ │ │ @@ -198,71 +199,71 @@
│ │ │ │
In addition, please follow the following guidelines when committing code to
│ │ │ │ Django’s Git repository:
│ │ │ │
│ │ │ │
Never change the published history of django/django branches by force
│ │ │ │ pushing. If you absolutely must (for security reasons for example), first
│ │ │ │ discuss the situation with the team.
│ │ │ │ -
For any medium-to-big changes, where “medium-to-big” is according to
│ │ │ │ +
For any medium-to-big changes, where «medium-to-big» is according to
│ │ │ │ your judgment, please bring things up on the Django Forum or
│ │ │ │ django-developers mailing list before making the change.
│ │ │ │
If you bring something up and nobody responds, please don’t take that
│ │ │ │ to mean your idea is great and should be implemented immediately because
│ │ │ │ nobody contested it. Everyone doesn’t always have a lot of time to read
│ │ │ │ mailing list discussions immediately, so you may have to wait a couple of
│ │ │ │ days before getting a response.
│ │ │ │
│ │ │ │
Write detailed commit messages in the past tense, not present tense.
│ │ │ │
│ │ │ │ -
Good: “Fixed Unicode bug in RSS API.”
│ │ │ │ -
Bad: “Fixes Unicode bug in RSS API.”
│ │ │ │ -
Bad: “Fixing Unicode bug in RSS API.”
│ │ │ │ +
Good: «Fixed Unicode bug in RSS API.»
│ │ │ │ +
Bad: «Fixes Unicode bug in RSS API.»
│ │ │ │ +
Bad: «Fixing Unicode bug in RSS API.»
│ │ │ │
│ │ │ │
The commit message should be in lines of 72 chars maximum. There should be
│ │ │ │ a subject line, separated by a blank line and then paragraphs of 72 char
│ │ │ │ lines. The limits are soft. For the subject line, shorter is better. In the
│ │ │ │ body of the commit message more detail is better than less:
│ │ │ │
Fixed #18307 -- Added git workflow guidelines.
│ │ │ │
│ │ │ │ Refactored the Django's documentation to remove mentions of SVN
│ │ │ │ specific tasks. Added guidelines of how to use Git, GitHub, and
│ │ │ │ how to use pull request together with Trac instead.
│ │ │ │
│ │ │ │
│ │ │ │ -
Credit the contributors in the commit message: “Thanks A for the report and B
│ │ │ │ -for review.” Use git’s Co-Authored-By as appropriate.
│ │ │ │ +
Credit the contributors in the commit message: «Thanks A for the report and B
│ │ │ │ +for review.» Use git’s Co-Authored-By as appropriate.
│ │ │ │
│ │ │ │
For commits to a branch, prefix the commit message with the branch name.
│ │ │ │ -For example: “[1.4.x] Fixed #xxxxx – Added support for mind reading.”
│ │ │ │ +For example: «[1.4.x] Fixed #xxxxx – Added support for mind reading.»
│ │ │ │
Limit commits to the most granular change that makes sense. This means,
│ │ │ │ use frequent small commits rather than infrequent large commits. For
│ │ │ │ example, if implementing feature X requires a small change to library Y,
│ │ │ │ first commit the change to library Y, then commit feature X in a separate
│ │ │ │ commit. This goes a long way in helping everyone follow your changes.
│ │ │ │
Separate bug fixes from feature changes. Bugfixes may need to be backported
│ │ │ │ to the stable branch, according to Supported versions.
│ │ │ │
If your commit closes a ticket in the Django ticket tracker, begin
│ │ │ │ -your commit message with the text “Fixed #xxxxx”, where “xxxxx” is the
│ │ │ │ -number of the ticket your commit fixes. Example: “Fixed #123 – Added
│ │ │ │ -whizbang feature.”. We’ve rigged Trac so that any commit message in that
│ │ │ │ +your commit message with the text «Fixed #xxxxx», where «xxxxx» is the
│ │ │ │ +number of the ticket your commit fixes. Example: «Fixed #123 – Added
│ │ │ │ +whizbang feature.». We’ve rigged Trac so that any commit message in that
│ │ │ │ format will automatically close the referenced ticket and post a comment
│ │ │ │ to it with the full commit message.
│ │ │ │
For the curious, we’re using a Trac plugin for this.
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
Note that the Trac integration doesn’t know anything about pull requests.
│ │ │ │ -So if you try to close a pull request with the phrase “closes #400” in your
│ │ │ │ +So if you try to close a pull request with the phrase «closes #400» in your
│ │ │ │ commit message, GitHub will close the pull request, but the Trac plugin
│ │ │ │ will not close the same numbered ticket in Trac.
│ │ │ │
│ │ │ │
│ │ │ │
If your commit references a ticket in the Django ticket tracker but
│ │ │ │ -does not close the ticket, include the phrase “Refs #xxxxx”, where “xxxxx”
│ │ │ │ +does not close the ticket, include the phrase «Refs #xxxxx», where «xxxxx»
│ │ │ │ is the number of the ticket your commit references. This will automatically
│ │ │ │ post a comment to the appropriate ticket.
│ │ │ │
Write commit messages for backports using this pattern:
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ CCoommmmiittttiinngg ccooddee_?¶ ************
│ │ │ │ │ This section is addressed to the mergers and to anyone interested in knowing
│ │ │ │ │ how code gets committed into Django. If you’re a community member who wants to
│ │ │ │ │ contribute code to Django, look at _W_o_r_k_i_n_g_ _w_i_t_h_ _G_i_t_ _a_n_d_ _G_i_t_H_u_b instead.
│ │ │ │ │ ********** HHaannddlliinngg ppuullll rreeqquueessttss_?¶ **********
│ │ │ │ │ @@ -61,15 +61,15 @@
│ │ │ │ │ ...\> git push upstream main
│ │ │ │ │ ...\> REM Delete the pull request branch.
│ │ │ │ │ ...\> git branch -d pr/xxxx
│ │ │ │ │ Force push to the branch after rebasing on main but before merging and pushing
│ │ │ │ │ to upstream. This allows the commit hashes on main and the branch to match
│ │ │ │ │ which automatically closes the pull request.
│ │ │ │ │ If a pull request doesn’t need to be merged as multiple commits, you can use
│ │ │ │ │ -GitHub’s “Squash and merge” button on the website. Edit the commit message as
│ │ │ │ │ +GitHub’s «Squash and merge» button on the website. Edit the commit message as
│ │ │ │ │ needed to conform to _t_h_e_ _g_u_i_d_e_l_i_n_e_s and remove the pull request number that’s
│ │ │ │ │ automatically appended to the message’s first line.
│ │ │ │ │ When rewriting the commit history of a pull request, the goal is to make
│ │ │ │ │ Django’s commit history as usable as possible:
│ │ │ │ │ * If a patch contains back-and-forth commits, then rewrite those into one.
│ │ │ │ │ For example, if a commit adds some code and a second commit fixes
│ │ │ │ │ stylistic issues introduced in the first commit, those commits should be
│ │ │ │ │ @@ -88,60 +88,60 @@
│ │ │ │ │ community, getting work done, and having a usable commit history.
│ │ │ │ │ ********** CCoommmmiittttiinngg gguuiiddeelliinneess_?¶ **********
│ │ │ │ │ In addition, please follow the following guidelines when committing code to
│ │ │ │ │ Django’s Git repository:
│ │ │ │ │ * Never change the published history of django/django branches by force
│ │ │ │ │ pushing. If you absolutely must (for security reasons for example), first
│ │ │ │ │ discuss the situation with the team.
│ │ │ │ │ - * For any medium-to-big changes, where “medium-to-big” is according to your
│ │ │ │ │ + * For any medium-to-big changes, where «medium-to-big» is according to your
│ │ │ │ │ judgment, please bring things up on the _D_j_a_n_g_o_ _F_o_r_u_m or _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s
│ │ │ │ │ mailing list before making the change.
│ │ │ │ │ If you bring something up and nobody responds, please don’t take that to
│ │ │ │ │ mean your idea is great and should be implemented immediately because
│ │ │ │ │ nobody contested it. Everyone doesn’t always have a lot of time to read
│ │ │ │ │ mailing list discussions immediately, so you may have to wait a couple of
│ │ │ │ │ days before getting a response.
│ │ │ │ │ * Write detailed commit messages in the past tense, not present tense.
│ │ │ │ │ - o Good: “Fixed Unicode bug in RSS API.”
│ │ │ │ │ - o Bad: “Fixes Unicode bug in RSS API.”
│ │ │ │ │ - o Bad: “Fixing Unicode bug in RSS API.”
│ │ │ │ │ + o Good: «Fixed Unicode bug in RSS API.»
│ │ │ │ │ + o Bad: «Fixes Unicode bug in RSS API.»
│ │ │ │ │ + o Bad: «Fixing Unicode bug in RSS API.»
│ │ │ │ │ The commit message should be in lines of 72 chars maximum. There should
│ │ │ │ │ be a subject line, separated by a blank line and then paragraphs of 72
│ │ │ │ │ char lines. The limits are soft. For the subject line, shorter is better.
│ │ │ │ │ In the body of the commit message more detail is better than less:
│ │ │ │ │ Fixed #18307 -- Added git workflow guidelines.
│ │ │ │ │
│ │ │ │ │ Refactored the Django's documentation to remove mentions of SVN
│ │ │ │ │ specific tasks. Added guidelines of how to use Git, GitHub, and
│ │ │ │ │ how to use pull request together with Trac instead.
│ │ │ │ │ - Credit the contributors in the commit message: “Thanks A for the report
│ │ │ │ │ - and B for review.” Use git’s _C_o_-_A_u_t_h_o_r_e_d_-_B_y as appropriate.
│ │ │ │ │ + Credit the contributors in the commit message: «Thanks A for the report
│ │ │ │ │ + and B for review.» Use git’s _C_o_-_A_u_t_h_o_r_e_d_-_B_y as appropriate.
│ │ │ │ │ * For commits to a branch, prefix the commit message with the branch name.
│ │ │ │ │ - For example: “[1.4.x] Fixed #xxxxx – Added support for mind reading.”
│ │ │ │ │ + For example: «[1.4.x] Fixed #xxxxx – Added support for mind reading.»
│ │ │ │ │ * Limit commits to the most granular change that makes sense. This means,
│ │ │ │ │ use frequent small commits rather than infrequent large commits. For
│ │ │ │ │ example, if implementing feature X requires a small change to library Y,
│ │ │ │ │ first commit the change to library Y, then commit feature X in a separate
│ │ │ │ │ commit. This goes a lloonngg wwaayy in helping everyone follow your changes.
│ │ │ │ │ * Separate bug fixes from feature changes. Bugfixes may need to be
│ │ │ │ │ backported to the stable branch, according to _S_u_p_p_o_r_t_e_d_ _v_e_r_s_i_o_n_s.
│ │ │ │ │ * If your commit closes a ticket in the Django _t_i_c_k_e_t_ _t_r_a_c_k_e_r, begin your
│ │ │ │ │ - commit message with the text “Fixed #xxxxx”, where “xxxxx” is the number
│ │ │ │ │ - of the ticket your commit fixes. Example: “Fixed #123 – Added whizbang
│ │ │ │ │ - feature.”. We’ve rigged Trac so that any commit message in that format
│ │ │ │ │ + commit message with the text «Fixed #xxxxx», where «xxxxx» is the number
│ │ │ │ │ + of the ticket your commit fixes. Example: «Fixed #123 – Added whizbang
│ │ │ │ │ + feature.». We’ve rigged Trac so that any commit message in that format
│ │ │ │ │ will automatically close the referenced ticket and post a comment to it
│ │ │ │ │ with the full commit message.
│ │ │ │ │ For the curious, we’re using a _T_r_a_c_ _p_l_u_g_i_n for this.
│ │ │ │ │ -Note
│ │ │ │ │ +Nota
│ │ │ │ │ Note that the Trac integration doesn’t know anything about pull requests. So if
│ │ │ │ │ -you try to close a pull request with the phrase “closes #400” in your commit
│ │ │ │ │ +you try to close a pull request with the phrase «closes #400» in your commit
│ │ │ │ │ message, GitHub will close the pull request, but the Trac plugin will not close
│ │ │ │ │ the same numbered ticket in Trac.
│ │ │ │ │ * If your commit references a ticket in the Django _t_i_c_k_e_t_ _t_r_a_c_k_e_r but does
│ │ │ │ │ - nnoott close the ticket, include the phrase “Refs #xxxxx”, where “xxxxx” is
│ │ │ │ │ + nnoott close the ticket, include the phrase «Refs #xxxxx», where «xxxxx» is
│ │ │ │ │ the number of the ticket your commit references. This will automatically
│ │ │ │ │ post a comment to the appropriate ticket.
│ │ │ │ │ * Write commit messages for backports using this pattern:
│ │ │ │ │ [] Fixed --
│ │ │ │ │
│ │ │ │ │ Backport of from .
│ │ │ │ │ For example:
│ │ │ │ │ @@ -182,16 +182,16 @@
│ │ │ │ │ instance, if you did: git push upstream feature_antigravity, do a reverse
│ │ │ │ │ push: git push upstream :feature_antigravity.
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ * _C_o_m_m_i_t_t_i_n_g_ _c_o_d_e
│ │ │ │ │ o _H_a_n_d_l_i_n_g_ _p_u_l_l_ _r_e_q_u_e_s_t_s
│ │ │ │ │ o _C_o_m_m_i_t_t_i_n_g_ _g_u_i_d_e_l_i_n_e_s
│ │ │ │ │ o _R_e_v_e_r_t_i_n_g_ _c_o_m_m_i_t_s
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _J_a_v_a_S_c_r_i_p_t_ _c_o_d_e
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _W_r_i_t_i_n_g_ _d_o_c_u_m_e_n_t_a_t_i_o_n
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/internals/contributing/index.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Contributing to Django — Django 5.1b1 documentation
│ │ │ │ + Contributing to Django — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,15 +54,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
On the Django project page, choose the language you want to work on,
│ │ │ │ or – in case the language doesn’t exist yet –
│ │ │ │ -request a new language team by clicking on the “Request language” link
│ │ │ │ +request a new language team by clicking on the «Request language» link
│ │ │ │ and selecting the appropriate language.
│ │ │ │ -
Then, click the “Join this Team” button to become a member of this team.
│ │ │ │ +
Then, click the «Join this Team» button to become a member of this team.
│ │ │ │ Every team has at least one coordinator who is responsible to review
│ │ │ │ your membership request. You can also contact the team coordinator to clarify
│ │ │ │ procedural problems and handle the actual translation process.
│ │ │ │
Once you are a member of a team choose the translation resource you
│ │ │ │ -want to update on the team page. For example, the “core” resource refers
│ │ │ │ +want to update on the team page. For example, the «core» resource refers
│ │ │ │ to the translation catalog that contains all non-contrib translations.
│ │ │ │ -Each of the contrib apps also has a resource (prefixed with “contrib”).
│ │ │ │ +Each of the contrib apps also has a resource (prefixed with «contrib»).
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
For more information about how to use Transifex, read the
│ │ │ │ Transifex User Guide.
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Translations from Transifex are only integrated into the Django repository at
│ │ │ │ the time of a new feature release. We try to update
│ │ │ │ @@ -168,37 +169,37 @@
│ │ │ │
│ │ │ │ + title="capitolo successivo">Reporting bugs and requesting features
│ │ │ │
│ │ │ │
│ │ │ │ -
Quick search
│ │ │ │ +
Ricerca veloce
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Last update:
│ │ │ │ -
Jun 26, 2024
│ │ │ │ +
giu 26, 2024
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ LLooccaalliizziinngg DDjjaannggoo_?¶ ************
│ │ │ │ │ Various parts of Django, such as the admin site and validation error messages,
│ │ │ │ │ are internationalized. This means they display differently depending on each
│ │ │ │ │ user’s language or country. For this, Django uses the same internationalization
│ │ │ │ │ and localization infrastructure available to Django applications, described in
│ │ │ │ │ @@ -14,25 +14,25 @@
│ │ │ │ │ go to the _D_j_a_n_g_o_ _p_r_o_j_e_c_t_ _p_a_g_e. If you would like to help out with translating
│ │ │ │ │ or adding a language that isn’t yet translated, here’s what to do:
│ │ │ │ │ * Introduce yourself on the _D_j_a_n_g_o_ _i_n_t_e_r_n_a_t_i_o_n_a_l_i_z_a_t_i_o_n_ _f_o_r_u_m.
│ │ │ │ │ * Make sure you read the notes about _S_p_e_c_i_a_l_t_i_e_s_ _o_f_ _D_j_a_n_g_o_ _t_r_a_n_s_l_a_t_i_o_n.
│ │ │ │ │ * Sign up at _T_r_a_n_s_i_f_e_x and visit the _D_j_a_n_g_o_ _p_r_o_j_e_c_t_ _p_a_g_e.
│ │ │ │ │ * On the _D_j_a_n_g_o_ _p_r_o_j_e_c_t_ _p_a_g_e, choose the language you want to work on, oorr –
│ │ │ │ │ in case the language doesn’t exist yet – request a new language team by
│ │ │ │ │ - clicking on the “Request language” link and selecting the appropriate
│ │ │ │ │ + clicking on the «Request language» link and selecting the appropriate
│ │ │ │ │ language.
│ │ │ │ │ - * Then, click the “Join this Team” button to become a member of this team.
│ │ │ │ │ + * Then, click the «Join this Team» button to become a member of this team.
│ │ │ │ │ Every team has at least one coordinator who is responsible to review your
│ │ │ │ │ membership request. You can also contact the team coordinator to clarify
│ │ │ │ │ procedural problems and handle the actual translation process.
│ │ │ │ │ * Once you are a member of a team choose the translation resource you want
│ │ │ │ │ - to update on the team page. For example, the “core” resource refers to
│ │ │ │ │ + to update on the team page. For example, the «core» resource refers to
│ │ │ │ │ the translation catalog that contains all non-contrib translations. Each
│ │ │ │ │ - of the contrib apps also has a resource (prefixed with “contrib”).
│ │ │ │ │ - Note
│ │ │ │ │ + of the contrib apps also has a resource (prefixed with «contrib»).
│ │ │ │ │ + Nota
│ │ │ │ │ For more information about how to use Transifex, read the _T_r_a_n_s_i_f_e_x_ _U_s_e_r
│ │ │ │ │ _G_u_i_d_e.
│ │ │ │ │ Translations from Transifex are only integrated into the Django repository at
│ │ │ │ │ the time of a new _f_e_a_t_u_r_e_ _r_e_l_e_a_s_e. We try to update them a second time during
│ │ │ │ │ one of the following _p_a_t_c_h_ _r_e_l_e_a_s_es, but that depends on the translation
│ │ │ │ │ manager’s availability. So don’t miss the string freeze period (between the
│ │ │ │ │ release candidate and the feature release) to take the opportunity to complete
│ │ │ │ │ @@ -57,16 +57,16 @@
│ │ │ │ │ documentation website. Only translations for the latest stable Django release
│ │ │ │ │ are updated.
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ * _L_o_c_a_l_i_z_i_n_g_ _D_j_a_n_g_o
│ │ │ │ │ o _T_r_a_n_s_l_a_t_i_o_n_s
│ │ │ │ │ o _F_o_r_m_a_t_s
│ │ │ │ │ o _D_o_c_u_m_e_n_t_a_t_i_o_n
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _W_r_i_t_i_n_g_ _d_o_c_u_m_e_n_t_a_t_i_o_n
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _R_e_p_o_r_t_i_n_g_ _b_u_g_s_ _a_n_d_ _r_e_q_u_e_s_t_i_n_g_ _f_e_a_t_u_r_e_s
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/internals/contributing/new-contributors.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Advice for new contributors — Django 5.1b1 documentation
│ │ │ │ + Advice for new contributors — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,15 +54,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Django’s documentation is great but it can always be improved. Did you find
│ │ │ │ a typo? Do you think that something should be clarified? Go ahead and
│ │ │ │ suggest a documentation patch! See also the guide on
│ │ │ │ Writing documentation.
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
The reports page contains links to many useful Trac queries, including
│ │ │ │ several that are useful for triaging tickets and reviewing patches as
│ │ │ │ suggested above.
│ │ │ │
│ │ │ │
│ │ │ │
Sign the Contributor License Agreement
│ │ │ │
The code that you write belongs to you or your employer. If your
│ │ │ │ @@ -142,15 +143,15 @@
│ │ │ │ some advice to make your work on Django more useful and rewarding.
│ │ │ │
│ │ │ │
Pick a subject area that you care about, that you are familiar with, or
│ │ │ │ that you want to learn about
│ │ │ │
You don’t already have to be an expert on the area you want to work on; you
│ │ │ │ become an expert through your ongoing contributions to the code.
│ │ │ │
│ │ │ │ -
Analyze tickets’ context and history
│ │ │ │ +
Analyze tickets” context and history
│ │ │ │
Trac isn’t an absolute; the context is just as important as the words.
│ │ │ │ When reading Trac, you need to take into account who says things, and when
│ │ │ │ they were said. Support for an idea two years ago doesn’t necessarily mean
│ │ │ │ that the idea will still have support. You also need to pay attention to who
│ │ │ │ hasn’t spoken – for example, if an experienced contributor hasn’t been
│ │ │ │ recently involved in a discussion, then a ticket may not have the support
│ │ │ │ required to get into Django.
│ │ │ │ @@ -162,16 +163,16 @@
│ │ │ │
If you’re going to engage in a big task, make sure that your idea has
│ │ │ │ support first
│ │ │ │
This means getting someone else to confirm that a bug is real before you fix
│ │ │ │ the issue, and ensuring that there’s consensus on a proposed feature before
│ │ │ │ you go implementing it.
│ │ │ │
│ │ │ │
Be bold! Leave feedback!
│ │ │ │ -
Sometimes it can be scary to put your opinion out to the world and say “this
│ │ │ │ -ticket is correct” or “this patch needs work”, but it’s the only way the
│ │ │ │ +
Sometimes it can be scary to put your opinion out to the world and say «this
│ │ │ │ +ticket is correct» or «this patch needs work», but it’s the only way the
│ │ │ │ project moves forward. The contributions of the broad Django community
│ │ │ │ ultimately have a much greater impact than that of any one person. We can’t
│ │ │ │ do it without you!
│ │ │ │
│ │ │ │
Err on the side of caution when marking things Ready For Check-in
│ │ │ │
If you’re really not certain if a ticket is ready, don’t mark it as
│ │ │ │ such. Leave a comment instead, letting others know your thoughts. If you’re
│ │ │ │ @@ -180,17 +181,17 @@
│ │ │ │
│ │ │ │
Wait for feedback, and respond to feedback that you receive
│ │ │ │
Focus on one or two tickets, see them through from start to finish, and
│ │ │ │ repeat. The shotgun approach of taking on lots of tickets and letting some
│ │ │ │ fall by the wayside ends up doing more harm than good.
│ │ │ │
│ │ │ │
Be rigorous
│ │ │ │ -
When we say “PEP 8, and must have docs and tests”, we mean it. If a patch
│ │ │ │ +
When we say «PEP 8, and must have docs and tests», we mean it. If a patch
│ │ │ │ doesn’t have docs and tests, there had better be a good reason. Arguments
│ │ │ │ -like “I couldn’t find any existing tests of this feature” don’t carry much
│ │ │ │ +like «I couldn’t find any existing tests of this feature» don’t carry much
│ │ │ │ weight–while it may be true, that means you have the extra-important job of
│ │ │ │ writing the very first tests for that feature, not that you get a pass from
│ │ │ │ writing tests altogether.
│ │ │ │
│ │ │ │
Be patient
│ │ │ │
It’s not always easy for your ticket or your patch to be reviewed quickly.
│ │ │ │ This isn’t personal. There are a lot of tickets and pull requests to get
│ │ │ │ @@ -224,37 +225,37 @@
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ AAddvviiccee ffoorr nneeww ccoonnttrriibbuuttoorrss_?¶ ************
│ │ │ │ │ New contributor and not sure what to do? Want to help but just don’t know how
│ │ │ │ │ to get started? This is the section for you.
│ │ │ │ │ Get up and running!
│ │ │ │ │ If you are new to contributing to Django, the _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _c_o_n_t_r_i_b_u_t_i_o_n
│ │ │ │ │ @@ -34,15 +34,15 @@
│ │ │ │ │ functions as expected. Updating a patch is both useful and important! See
│ │ │ │ │ more on _S_u_b_m_i_t_t_i_n_g_ _p_a_t_c_h_e_s.
│ │ │ │ │ * WWrriittee ssoommee ddooccuummeennttaattiioonn
│ │ │ │ │ Django’s documentation is great but it can always be improved. Did you
│ │ │ │ │ find a typo? Do you think that something should be clarified? Go ahead
│ │ │ │ │ and suggest a documentation patch! See also the guide on _W_r_i_t_i_n_g
│ │ │ │ │ _d_o_c_u_m_e_n_t_a_t_i_o_n.
│ │ │ │ │ - Note
│ │ │ │ │ + Nota
│ │ │ │ │ The _r_e_p_o_r_t_s_ _p_a_g_e contains links to many useful Trac queries, including
│ │ │ │ │ several that are useful for triaging tickets and reviewing patches as
│ │ │ │ │ suggested above.
│ │ │ │ │ * SSiiggnn tthhee CCoonnttrriibbuuttoorr LLiicceennssee AAggrreeeemmeenntt
│ │ │ │ │ The code that you write belongs to you or your employer. If your
│ │ │ │ │ contribution is more than one or two lines of code, you need to sign the
│ │ │ │ │ _C_L_A. See the _C_o_n_t_r_i_b_u_t_o_r_ _L_i_c_e_n_s_e_ _A_g_r_e_e_m_e_n_t_ _F_A_Q for a more thorough
│ │ │ │ │ @@ -50,15 +50,15 @@
│ │ │ │ │ ********** GGuuiiddeelliinneess_?¶ **********
│ │ │ │ │ As a newcomer on a large project, it’s easy to experience frustration. Here’s
│ │ │ │ │ some advice to make your work on Django more useful and rewarding.
│ │ │ │ │ * PPiicckk aa ssuubbjjeecctt aarreeaa tthhaatt yyoouu ccaarree aabboouutt,, tthhaatt yyoouu aarree ffaammiilliiaarr wwiitthh,, oorr
│ │ │ │ │ tthhaatt yyoouu wwaanntt ttoo lleeaarrnn aabboouutt
│ │ │ │ │ You don’t already have to be an expert on the area you want to work on;
│ │ │ │ │ you become an expert through your ongoing contributions to the code.
│ │ │ │ │ - * AAnnaallyyzzee ttiicckkeettss?’ ccoonntteexxtt aanndd hhiissttoorryy
│ │ │ │ │ + * AAnnaallyyzzee ttiicckkeettss?” ccoonntteexxtt aanndd hhiissttoorryy
│ │ │ │ │ Trac isn’t an absolute; the context is just as important as the words.
│ │ │ │ │ When reading Trac, you need to take into account who says things, and
│ │ │ │ │ when they were said. Support for an idea two years ago doesn’t
│ │ │ │ │ necessarily mean that the idea will still have support. You also need to
│ │ │ │ │ pay attention to who hhaassnn?’tt spoken – for example, if an experienced
│ │ │ │ │ contributor hasn’t been recently involved in a discussion, then a ticket
│ │ │ │ │ may not have the support required to get into Django.
│ │ │ │ │ @@ -68,31 +68,31 @@
│ │ │ │ │ * IIff yyoouu?’rree ggooiinngg ttoo eennggaaggee iinn aa bbiigg ttaasskk,, mmaakkee ssuurree tthhaatt yyoouurr iiddeeaa hhaass
│ │ │ │ │ ssuuppppoorrtt ffiirrsstt
│ │ │ │ │ This means getting someone else to confirm that a bug is real before you
│ │ │ │ │ fix the issue, and ensuring that there’s consensus on a proposed feature
│ │ │ │ │ before you go implementing it.
│ │ │ │ │ * BBee bboolldd!! LLeeaavvee ffeeeeddbbaacckk!!
│ │ │ │ │ Sometimes it can be scary to put your opinion out to the world and say
│ │ │ │ │ - “this ticket is correct” or “this patch needs work”, but it’s the only
│ │ │ │ │ + «this ticket is correct» or «this patch needs work», but it’s the only
│ │ │ │ │ way the project moves forward. The contributions of the broad Django
│ │ │ │ │ community ultimately have a much greater impact than that of any one
│ │ │ │ │ person. We can’t do it without yyoouu!
│ │ │ │ │ * EErrrr oonn tthhee ssiiddee ooff ccaauuttiioonn wwhheenn mmaarrkkiinngg tthhiinnggss RReeaaddyy FFoorr CChheecckk--iinn
│ │ │ │ │ If you’re really not certain if a ticket is ready, don’t mark it as such.
│ │ │ │ │ Leave a comment instead, letting others know your thoughts. If you’re
│ │ │ │ │ mostly certain, but not completely certain, you might also try asking on
│ │ │ │ │ IRC to see if someone else can confirm your suspicions.
│ │ │ │ │ * WWaaiitt ffoorr ffeeeeddbbaacckk,, aanndd rreessppoonndd ttoo ffeeeeddbbaacckk tthhaatt yyoouu rreecceeiivvee
│ │ │ │ │ Focus on one or two tickets, see them through from start to finish, and
│ │ │ │ │ repeat. The shotgun approach of taking on lots of tickets and letting
│ │ │ │ │ some fall by the wayside ends up doing more harm than good.
│ │ │ │ │ * BBee rriiggoorroouuss
│ │ │ │ │ - When we say “_PP_EE_PP_ _88, and must have docs and tests”, we mean it. If a patch
│ │ │ │ │ + When we say «_PP_EE_PP_ _88, and must have docs and tests», we mean it. If a patch
│ │ │ │ │ doesn’t have docs and tests, there had better be a good reason. Arguments
│ │ │ │ │ - like “I couldn’t find any existing tests of this feature” don’t carry
│ │ │ │ │ + like «I couldn’t find any existing tests of this feature» don’t carry
│ │ │ │ │ much weight–while it may be true, that means you have the extra-important
│ │ │ │ │ job of writing the very first tests for that feature, not that you get a
│ │ │ │ │ pass from writing tests altogether.
│ │ │ │ │ * BBee ppaattiieenntt
│ │ │ │ │ It’s not always easy for your ticket or your patch to be reviewed
│ │ │ │ │ quickly. This isn’t personal. There are a lot of tickets and pull
│ │ │ │ │ requests to get through.
│ │ │ │ │ @@ -104,16 +104,16 @@
│ │ │ │ │ of time for your patch to be reviewed.
│ │ │ │ │ Finally, a well-timed reminder can help. See _c_o_n_t_r_i_b_u_t_i_n_g_ _c_o_d_e_ _F_A_Q for
│ │ │ │ │ ideas here.
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ * _A_d_v_i_c_e_ _f_o_r_ _n_e_w_ _c_o_n_t_r_i_b_u_t_o_r_s
│ │ │ │ │ o _F_i_r_s_t_ _s_t_e_p_s
│ │ │ │ │ o _G_u_i_d_e_l_i_n_e_s
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _C_o_n_t_r_i_b_u_t_i_n_g_ _t_o_ _D_j_a_n_g_o
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _C_o_n_t_r_i_b_u_t_i_n_g_ _c_o_d_e
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/internals/contributing/triaging-tickets.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Triaging tickets — Django 5.1b1 documentation
│ │ │ │ + Triaging tickets — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,15 +54,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -91,15 +92,15 @@
│ │ │ │ intentions – fertilize the weeds and poison the roses. It’s the job of the
│ │ │ │ community as a whole to self-manage, keep the problems to a minimum, and
│ │ │ │ educate those coming into the community so that they can become valuable
│ │ │ │ contributing members.
│ │ │ │
Similarly, while we aim for Trac to be a perfect representation of the state of
│ │ │ │ Django’s progress, we acknowledge that this will not happen. By distributing
│ │ │ │ the load of Trac maintenance to the community, we accept that there will be
│ │ │ │ -mistakes. Trac is “mostly accurate”, and we give allowances for the fact that
│ │ │ │ +mistakes. Trac is «mostly accurate», and we give allowances for the fact that
│ │ │ │ sometimes it will be wrong. That’s okay. We’re perfectionists with deadlines.
│ │ │ │
We rely on the community to keep participating, keep tickets as accurate as
│ │ │ │ possible, and raise issues for discussion on our mailing lists when there is
│ │ │ │ confusion or disagreement.
│ │ │ │
Django is a community project, and every contribution helps. We can’t do this
│ │ │ │ without you!
│ │ │ │
│ │ │ │ @@ -126,24 +127,24 @@
│ │ │ │ Django is a community project, and we encourage triage by the
│ │ │ │ community.
│ │ │ │
│ │ │ │
By way of example, here we see the lifecycle of an average ticket:
│ │ │ │
│ │ │ │
Alice creates a ticket and sends an incomplete pull request (no tests,
│ │ │ │ incorrect implementation).
│ │ │ │ -
Bob reviews the pull request, marks the ticket as “Accepted”, “needs tests”,
│ │ │ │ -and “patch needs improvement”, and leaves a comment telling Alice how the
│ │ │ │ +
Bob reviews the pull request, marks the ticket as «Accepted», «needs tests»,
│ │ │ │ +and «patch needs improvement», and leaves a comment telling Alice how the
│ │ │ │ patch could be improved.
│ │ │ │
Alice updates the pull request, adding tests (but not changing the
│ │ │ │ implementation). She removes the two flags.
│ │ │ │ -
Charlie reviews the pull request and resets the “patch needs improvement”
│ │ │ │ +
Charlie reviews the pull request and resets the «patch needs improvement»
│ │ │ │ flag with another comment about improving the implementation.
│ │ │ │
Alice updates the pull request, fixing the implementation. She removes the
│ │ │ │ -“patch needs improvement” flag.
│ │ │ │ -
Daisy reviews the pull request and marks the ticket as “Ready for checkin”.
The ticket has not been reviewed by anyone who felt qualified to make a
│ │ │ │ judgment about whether the ticket contained a valid issue, a viable feature,
│ │ │ │ or ought to be closed for any of the various reasons.
The big gray area! The absolute meaning of “accepted” is that the issue
│ │ │ │ +
The big gray area! The absolute meaning of «accepted» is that the issue
│ │ │ │ described in the ticket is valid and is in some stage of being worked on.
│ │ │ │ Beyond that there are several considerations:
│ │ │ │
│ │ │ │
Accepted + No Flags
│ │ │ │
The ticket is valid, but no one has submitted a patch for it yet. Often this
│ │ │ │ means you could safely start writing a patch for it. This is generally more
│ │ │ │ true for the case of accepted bugs than accepted features. A ticket for a bug
│ │ │ │ @@ -177,16 +178,16 @@
│ │ │ │
The ticket is waiting for people to review the supplied patch. This means
│ │ │ │ downloading the patch and trying it out, verifying that it contains tests
│ │ │ │ and docs, running the test suite with the included patch, and leaving
│ │ │ │ feedback on the ticket.
│ │ │ │
│ │ │ │
Accepted + Has Patch + Needs …
│ │ │ │
This means the ticket has been reviewed, and has been found to need further
│ │ │ │ -work. “Needs tests” and “Needs documentation” are self-explanatory. “Patch
│ │ │ │ -needs improvement” will generally be accompanied by a comment on the ticket
│ │ │ │ +work. «Needs tests» and «Needs documentation» are self-explanatory. «Patch
│ │ │ │ +needs improvement» will generally be accompanied by a comment on the ticket
│ │ │ │ explaining what is needed to improve the code.
This flag is used for tickets with patches that need associated
│ │ │ │ documentation. Complete documentation of features is a prerequisite
│ │ │ │ @@ -270,15 +271,15 @@
│ │ │ │
The severity attribute is used to identify blockers, that is, issues that
│ │ │ │ should get fixed before releasing the next version of Django. Typically those
│ │ │ │ issues are bugs causing regressions from earlier versions or potentially
│ │ │ │ causing severe data losses. This attribute is quite rarely used and the vast
│ │ │ │ -majority of tickets have a severity of “Normal”.
│ │ │ │ +majority of tickets have a severity of «Normal».
│ │ │ │
│ │ │ │
│ │ │ │
With this field you may label a ticket with multiple keywords. This can be
│ │ │ │ useful, for example, to group several tickets on the same theme. Keywords can
│ │ │ │ either be comma or space separated. Keyword search finds the keyword string
│ │ │ │ anywhere in the keywords. For example, clicking on a ticket with the keyword
│ │ │ │ -“form” will yield similar tickets tagged with keywords containing strings such
│ │ │ │ -as “formset”, “modelformset”, and “ManagementForm”.
│ │ │ │ +«form» will yield similar tickets tagged with keywords containing strings such
│ │ │ │ +as «formset», «modelformset», and «ManagementForm».
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
When a ticket has completed its useful lifecycle, it’s time for it to be
│ │ │ │ closed. Closing a ticket is a big responsibility, though. You have to be sure
│ │ │ │ that the issue is really resolved, and you need to keep in mind that the
│ │ │ │ @@ -339,21 +340,21 @@
│ │ │ │ a bug report or feature request at all (for example, some new users
│ │ │ │ submit support queries as tickets).
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
wontfix
Used when someone decides that the request isn’t appropriate for
│ │ │ │ -consideration in Django. Sometimes a ticket is closed as “wontfix” with a
│ │ │ │ +consideration in Django. Sometimes a ticket is closed as «wontfix» with a
│ │ │ │ request for the reporter to start a discussion on the Django Forum or
│ │ │ │ django-developers mailing list if they feel differently from the
│ │ │ │ rationale provided by the person who closed the ticket. Other times, a
│ │ │ │ discussion precedes the decision to close a ticket. Always use the forum
│ │ │ │ or mailing list to get a consensus before reopening tickets closed as
│ │ │ │ -“wontfix”.
│ │ │ │ +«wontfix».
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
duplicate
Used when another ticket covers the same issue. By closing duplicate
│ │ │ │ tickets, we keep all the discussion in one place, which helps
│ │ │ │ everyone.
│ │ │ │ @@ -373,63 +374,63 @@
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
If you believe that the ticket was closed in error – because you’re
│ │ │ │ still having the issue, or it’s popped up somewhere else, or the triagers have
│ │ │ │ made a mistake – please reopen the ticket and provide further information.
│ │ │ │ -Again, please do not reopen tickets that have been marked as “wontfix” and
│ │ │ │ +Again, please do not reopen tickets that have been marked as «wontfix» and
│ │ │ │ bring the issue to the Django Forum or django-developers instead.
Closing “Unreviewed” tickets as “invalid”, “worksforme”, or “duplicate”, or
│ │ │ │ -“wontfix”.
│ │ │ │ -
Closing “Unreviewed” tickets as “needsinfo” when the description is too
│ │ │ │ +
Closing «Unreviewed» tickets as «invalid», «worksforme», or «duplicate», or
│ │ │ │ +«wontfix».
│ │ │ │ +
Closing «Unreviewed» tickets as «needsinfo» when the description is too
│ │ │ │ sparse to be actionable, or when they’re feature requests requiring a
│ │ │ │ discussion on the Django Forum or django-developers.
│ │ │ │ -
Correcting the “Needs tests”, “Needs documentation”, or “Has patch”
│ │ │ │ +
Correcting the «Needs tests», «Needs documentation», or «Has patch»
│ │ │ │ flags for tickets where they are incorrectly set.
│ │ │ │ -
Setting the “Easy pickings” flag for tickets that are small and
│ │ │ │ +
Setting the «Easy pickings» flag for tickets that are small and
│ │ │ │ relatively straightforward.
│ │ │ │
Set the type of tickets that are still uncategorized.
│ │ │ │
Checking that old tickets are still valid. If a ticket hasn’t seen
│ │ │ │ any activity in a long time, it’s possible that the problem has been
│ │ │ │ fixed but the ticket hasn’t yet been closed.
│ │ │ │
Identifying trends and themes in the tickets. If there are a lot of bug
│ │ │ │ reports about a particular part of Django, it may indicate we should
│ │ │ │ consider refactoring that part of the code. If a trend is emerging,
│ │ │ │ you should raise it for discussion (referencing the relevant tickets)
│ │ │ │ on the Django Forum or django-developers.
│ │ │ │
Verify if patches submitted by other users are correct. If they are correct
│ │ │ │ and also contain appropriate documentation and tests then move them to the
│ │ │ │ -“Ready for Checkin” stage. If they are not correct then leave a comment to
│ │ │ │ -explain why and set the corresponding flags (“Patch needs improvement”,
│ │ │ │ -“Needs tests” etc.).
│ │ │ │ +«Ready for Checkin» stage. If they are not correct then leave a comment to
│ │ │ │ +explain why and set the corresponding flags («Patch needs improvement»,
│ │ │ │ +«Needs tests» etc.).
│ │ │ │
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
The Reports page contains links to many useful Trac queries, including
│ │ │ │ several that are useful for triaging tickets and reviewing patches as
│ │ │ │ suggested above.
However, we do ask the following of all general community members working in
│ │ │ │ the ticket database:
│ │ │ │
│ │ │ │ -
Please don’t promote your own tickets to “Ready for checkin”. You
│ │ │ │ -may mark other people’s tickets that you’ve reviewed as “Ready for
│ │ │ │ -checkin”, but you should get at minimum one other community member to
│ │ │ │ +
Please don’t promote your own tickets to «Ready for checkin». You
│ │ │ │ +may mark other people’s tickets that you’ve reviewed as «Ready for
│ │ │ │ +checkin», but you should get at minimum one other community member to
│ │ │ │ review a patch that you submit.
│ │ │ │
Please don’t reverse a decision without posting a message to the
│ │ │ │ Django Forum or django-developers to find consensus.
│ │ │ │
If you’re unsure if you should be making a change, don’t make the
│ │ │ │ change but instead leave a comment with your concerns on the ticket,
│ │ │ │ or post a message to the Django Forum or django-developers. It’s okay to
│ │ │ │ be unsure, but your input is still valuable.
│ │ │ │ @@ -446,38 +447,38 @@
│ │ │ │ example, we’ll pretend we’re debugging a regression in migrations. After you’ve
│ │ │ │ written the test and confirmed that it fails on the latest main branch, put it
│ │ │ │ in a separate file that you can run standalone. For our example, we’ll pretend
│ │ │ │ we created tests/migrations/test_regression.py, which can be run with:
│ │ │ │
$./runtests.pymigrations.test_regression
│ │ │ │
│ │ │ │
│ │ │ │ -
Next, we mark the current point in history as being “bad” since the test fails:
│ │ │ │ +
Next, we mark the current point in history as being «bad» since the test fails:
Now, we need to find a point in git history before the regression was
│ │ │ │ introduced (i.e. a point where the test passes). Use something like
│ │ │ │ gitcheckoutHEAD~100 to check out an earlier revision (100 commits earlier,
│ │ │ │ -in this case). Check if the test fails. If so, mark that point as “bad”
│ │ │ │ +in this case). Check if the test fails. If so, mark that point as «bad»
│ │ │ │ (gitbisectbad), then check out an earlier revision and recheck. Once you
│ │ │ │ -find a revision where your test passes, mark it as “good”:
│ │ │ │ +find a revision where your test passes, mark it as «good»:
│ │ │ │
You should see gitbisect use a binary search to automatically checkout
│ │ │ │ -revisions between the good and bad commits until it finds the first “bad”
│ │ │ │ +revisions between the good and bad commits until it finds the first «bad»
│ │ │ │ commit where the test fails.
│ │ │ │
Now, report your results on the Trac ticket, and please include the regression
│ │ │ │ test as an attachment. When someone writes a fix for the bug, they’ll already
│ │ │ │ have your test as a starting point.
│ │ │ │ + title="capitolo successivo">Mailing lists and Forum
│ │ │ │
│ │ │ │
│ │ │ │ -
Quick search
│ │ │ │ +
Ricerca veloce
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Last update:
│ │ │ │ -
Jun 26, 2024
│ │ │ │ +
giu 26, 2024
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ TTrriiaaggiinngg ttiicckkeettss_?¶ ************
│ │ │ │ │ Django uses _T_r_a_c for managing the work on the code base. Trac is a community-
│ │ │ │ │ tended garden of the bugs people have found and the features people would like
│ │ │ │ │ to see added. As in any garden, sometimes there are weeds to be pulled and
│ │ │ │ │ sometimes there are flowers and vegetables that need picking. We need your help
│ │ │ │ │ @@ -13,15 +13,15 @@
│ │ │ │ │ intentions – fertilize the weeds and poison the roses. It’s the job of the
│ │ │ │ │ community as a whole to self-manage, keep the problems to a minimum, and
│ │ │ │ │ educate those coming into the community so that they can become valuable
│ │ │ │ │ contributing members.
│ │ │ │ │ Similarly, while we aim for Trac to be a perfect representation of the state of
│ │ │ │ │ Django’s progress, we acknowledge that this will not happen. By distributing
│ │ │ │ │ the load of Trac maintenance to the community, we accept that there will be
│ │ │ │ │ -mistakes. Trac is “mostly accurate”, and we give allowances for the fact that
│ │ │ │ │ +mistakes. Trac is «mostly accurate», and we give allowances for the fact that
│ │ │ │ │ sometimes it will be wrong. That’s okay. We’re perfectionists with deadlines.
│ │ │ │ │ We rely on the community to keep participating, keep tickets as accurate as
│ │ │ │ │ possible, and raise issues for discussion on our mailing lists when there is
│ │ │ │ │ confusion or disagreement.
│ │ │ │ │ Django is a community project, and every contribution helps. We can’t do this
│ │ │ │ │ without yyoouu!
│ │ │ │ │ ********** TTrriiaaggee wwoorrkkffllooww_?¶ **********
│ │ │ │ │ @@ -41,37 +41,37 @@
│ │ │ │ │ * Ticket triagers: anyone in the Django community who chooses to become
│ │ │ │ │ involved in Django’s development process. Our Trac installation is
│ │ │ │ │ intentionally left open to the public, and anyone can triage tickets.
│ │ │ │ │ Django is a community project, and we encourage _t_r_i_a_g_e_ _b_y_ _t_h_e_ _c_o_m_m_u_n_i_t_y.
│ │ │ │ │ By way of example, here we see the lifecycle of an average ticket:
│ │ │ │ │ * Alice creates a ticket and sends an incomplete pull request (no tests,
│ │ │ │ │ incorrect implementation).
│ │ │ │ │ - * Bob reviews the pull request, marks the ticket as “Accepted”, “needs
│ │ │ │ │ - tests”, and “patch needs improvement”, and leaves a comment telling Alice
│ │ │ │ │ + * Bob reviews the pull request, marks the ticket as «Accepted», «needs
│ │ │ │ │ + tests», and «patch needs improvement», and leaves a comment telling Alice
│ │ │ │ │ how the patch could be improved.
│ │ │ │ │ * Alice updates the pull request, adding tests (but not changing the
│ │ │ │ │ implementation). She removes the two flags.
│ │ │ │ │ - * Charlie reviews the pull request and resets the “patch needs improvement”
│ │ │ │ │ + * Charlie reviews the pull request and resets the «patch needs improvement»
│ │ │ │ │ flag with another comment about improving the implementation.
│ │ │ │ │ * Alice updates the pull request, fixing the implementation. She removes
│ │ │ │ │ - the “patch needs improvement” flag.
│ │ │ │ │ - * Daisy reviews the pull request and marks the ticket as “Ready for
│ │ │ │ │ - checkin”.
│ │ │ │ │ + the «patch needs improvement» flag.
│ │ │ │ │ + * Daisy reviews the pull request and marks the ticket as «Ready for
│ │ │ │ │ + checkin».
│ │ │ │ │ * Jacob, a _m_e_r_g_e_r, reviews the pull request and merges it.
│ │ │ │ │ Some tickets require much less feedback than this, but then again some tickets
│ │ │ │ │ require much much more.
│ │ │ │ │ ********** TTrriiaaggee ssttaaggeess_?¶ **********
│ │ │ │ │ Below we describe in more detail the various stages that a ticket may flow
│ │ │ │ │ through during its lifetime.
│ │ │ │ │ ******** UUnnrreevviieewweedd_?¶ ********
│ │ │ │ │ The ticket has not been reviewed by anyone who felt qualified to make a
│ │ │ │ │ judgment about whether the ticket contained a valid issue, a viable feature, or
│ │ │ │ │ ought to be closed for any of the various reasons.
│ │ │ │ │ ******** AAcccceepptteedd_?¶ ********
│ │ │ │ │ -The big gray area! The absolute meaning of “accepted” is that the issue
│ │ │ │ │ +The big gray area! The absolute meaning of «accepted» is that the issue
│ │ │ │ │ described in the ticket is valid and is in some stage of being worked on.
│ │ │ │ │ Beyond that there are several considerations:
│ │ │ │ │ * AAcccceepptteedd ++ NNoo FFllaaggss
│ │ │ │ │ The ticket is valid, but no one has submitted a patch for it yet. Often
│ │ │ │ │ this means you could safely start writing a patch for it. This is
│ │ │ │ │ generally more true for the case of accepted bugs than accepted features.
│ │ │ │ │ A ticket for a bug that has been accepted means that the issue has been
│ │ │ │ │ @@ -84,16 +84,16 @@
│ │ │ │ │ * AAcccceepptteedd ++ HHaass PPaattcchh
│ │ │ │ │ The ticket is waiting for people to review the supplied patch. This means
│ │ │ │ │ downloading the patch and trying it out, verifying that it contains tests
│ │ │ │ │ and docs, running the test suite with the included patch, and leaving
│ │ │ │ │ feedback on the ticket.
│ │ │ │ │ * AAcccceepptteedd ++ HHaass PPaattcchh ++ NNeeeeddss ?…
│ │ │ │ │ This means the ticket has been reviewed, and has been found to need
│ │ │ │ │ - further work. “Needs tests” and “Needs documentation” are self-
│ │ │ │ │ - explanatory. “Patch needs improvement” will generally be accompanied by a
│ │ │ │ │ + further work. «Needs tests» and «Needs documentation» are self-
│ │ │ │ │ + explanatory. «Patch needs improvement» will generally be accompanied by a
│ │ │ │ │ comment on the ticket explaining what is needed to improve the code.
│ │ │ │ │ ******** RReeaaddyy FFoorr CChheecckkiinn_?¶ ********
│ │ │ │ │ The ticket was reviewed by any member of the community other than the person
│ │ │ │ │ who supplied the patch and found to meet all the requirements for a commit-
│ │ │ │ │ ready patch. A _m_e_r_g_e_r now needs to give the patch a final review prior to being
│ │ │ │ │ committed.
│ │ │ │ │ There are a lot of pull requests. It can take a while for your patch to get
│ │ │ │ │ @@ -105,15 +105,15 @@
│ │ │ │ │ concrete actionable issues. They are enhancement requests that we might
│ │ │ │ │ consider adding someday to the framework if an excellent patch is submitted.
│ │ │ │ │ They are not a high priority.
│ │ │ │ │ ********** OOtthheerr ttrriiaaggee aattttrriibbuutteess_?¶ **********
│ │ │ │ │ A number of flags, appearing as checkboxes in Trac, can be set on a ticket:
│ │ │ │ │ ******** HHaass ppaattcchh_?¶ ********
│ │ │ │ │ This means the ticket has an associated _p_a_t_c_h. These will be reviewed to see if
│ │ │ │ │ -the patch is “good”.
│ │ │ │ │ +the patch is «good».
│ │ │ │ │ The following three fields (Needs documentation, Needs tests, Patch needs
│ │ │ │ │ improvement) apply only if a patch has been supplied.
│ │ │ │ │ ******** NNeeeeddss ddooccuummeennttaattiioonn_?¶ ********
│ │ │ │ │ This flag is used for tickets with patches that need associated documentation.
│ │ │ │ │ Complete documentation of features is a prerequisite before we can check them
│ │ │ │ │ into the codebase.
│ │ │ │ │ ******** NNeeeeddss tteessttss_?¶ ********
│ │ │ │ │ @@ -139,15 +139,15 @@
│ │ │ │ │ Django codebase they belong to. This makes tickets better organized and easier
│ │ │ │ │ to find.
│ │ │ │ │ ******** SSeevveerriittyy_?¶ ********
│ │ │ │ │ The sseevveerriittyy attribute is used to identify blockers, that is, issues that
│ │ │ │ │ should get fixed before releasing the next version of Django. Typically those
│ │ │ │ │ issues are bugs causing regressions from earlier versions or potentially
│ │ │ │ │ causing severe data losses. This attribute is quite rarely used and the vast
│ │ │ │ │ -majority of tickets have a severity of “Normal”.
│ │ │ │ │ +majority of tickets have a severity of «Normal».
│ │ │ │ │ ******** VVeerrssiioonn_?¶ ********
│ │ │ │ │ It is possible to use the vveerrssiioonn attribute to indicate in which version the
│ │ │ │ │ reported bug was identified.
│ │ │ │ │ ******** UUII//UUXX_?¶ ********
│ │ │ │ │ This flag is used for tickets that relate to User Interface and User
│ │ │ │ │ Experiences questions. For example, this flag would be appropriate for user-
│ │ │ │ │ facing features in forms or the admin interface.
│ │ │ │ │ @@ -155,16 +155,16 @@
│ │ │ │ │ You may add your username or email address to this field to be notified when
│ │ │ │ │ new contributions are made to the ticket.
│ │ │ │ │ ******** KKeeyywwoorrddss_?¶ ********
│ │ │ │ │ With this field you may label a ticket with multiple keywords. This can be
│ │ │ │ │ useful, for example, to group several tickets on the same theme. Keywords can
│ │ │ │ │ either be comma or space separated. Keyword search finds the keyword string
│ │ │ │ │ anywhere in the keywords. For example, clicking on a ticket with the keyword
│ │ │ │ │ -“form” will yield similar tickets tagged with keywords containing strings such
│ │ │ │ │ -as “formset”, “modelformset”, and “ManagementForm”.
│ │ │ │ │ +«form» will yield similar tickets tagged with keywords containing strings such
│ │ │ │ │ +as «formset», «modelformset», and «ManagementForm».
│ │ │ │ │ ********** CClloossiinngg TTiicckkeettss_?¶ **********
│ │ │ │ │ When a ticket has completed its useful lifecycle, it’s time for it to be
│ │ │ │ │ closed. Closing a ticket is a big responsibility, though. You have to be sure
│ │ │ │ │ that the issue is really resolved, and you need to keep in mind that the
│ │ │ │ │ reporter of the ticket may not be happy to have their ticket closed (unless
│ │ │ │ │ it’s fixed!). If you’re not certain about closing a ticket, leave a comment
│ │ │ │ │ with your thoughts instead.
│ │ │ │ │ @@ -190,75 +190,75 @@
│ │ │ │ │ Used if the ticket is found to be incorrect. This means that the
│ │ │ │ │ issue in the ticket is actually the result of a user error, or
│ │ │ │ │ describes a problem with something other than Django, or isn’t a
│ │ │ │ │ bug report or feature request at all (for example, some new users
│ │ │ │ │ submit support queries as tickets).
│ │ │ │ │ * wontfix
│ │ │ │ │ Used when someone decides that the request isn’t appropriate for
│ │ │ │ │ - consideration in Django. Sometimes a ticket is closed as “wontfix”
│ │ │ │ │ + consideration in Django. Sometimes a ticket is closed as «wontfix»
│ │ │ │ │ with a request for the reporter to start a discussion on the _D_j_a_n_g_o
│ │ │ │ │ _F_o_r_u_m or _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s mailing list if they feel differently
│ │ │ │ │ from the rationale provided by the person who closed the ticket.
│ │ │ │ │ Other times, a discussion precedes the decision to close a ticket.
│ │ │ │ │ Always use the forum or mailing list to get a consensus before
│ │ │ │ │ - reopening tickets closed as “wontfix”.
│ │ │ │ │ + reopening tickets closed as «wontfix».
│ │ │ │ │ * duplicate
│ │ │ │ │ Used when another ticket covers the same issue. By closing
│ │ │ │ │ duplicate tickets, we keep all the discussion in one place, which
│ │ │ │ │ helps everyone.
│ │ │ │ │ * worksforme
│ │ │ │ │ Used when the ticket doesn’t contain enough detail to replicate the
│ │ │ │ │ original bug.
│ │ │ │ │ * needsinfo
│ │ │ │ │ Used when the ticket does not contain enough information to
│ │ │ │ │ replicate the reported issue but is potentially still valid. The
│ │ │ │ │ ticket should be reopened when more information is supplied.
│ │ │ │ │ If you believe that the ticket was closed in error – because you’re still
│ │ │ │ │ having the issue, or it’s popped up somewhere else, or the triagers have made a
│ │ │ │ │ mistake – please reopen the ticket and provide further information. Again,
│ │ │ │ │ -please do not reopen tickets that have been marked as “wontfix” and bring the
│ │ │ │ │ +please do not reopen tickets that have been marked as «wontfix» and bring the
│ │ │ │ │ issue to the _D_j_a_n_g_o_ _F_o_r_u_m or _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s instead.
│ │ │ │ │ ********** HHooww ccaann II hheellpp wwiitthh ttrriiaaggiinngg??_?¶ **********
│ │ │ │ │ The triage process is primarily driven by community members. Really, AANNYYOONNEE can
│ │ │ │ │ help.
│ │ │ │ │ To get involved, start by _c_r_e_a_t_i_n_g_ _a_n_ _a_c_c_o_u_n_t_ _o_n_ _T_r_a_c. If you have an account
│ │ │ │ │ but have forgotten your password, you can reset it using the _p_a_s_s_w_o_r_d_ _r_e_s_e_t
│ │ │ │ │ _p_a_g_e.
│ │ │ │ │ Then, you can help out by:
│ │ │ │ │ - * Closing “Unreviewed” tickets as “invalid”, “worksforme”, or “duplicate”,
│ │ │ │ │ - or “wontfix”.
│ │ │ │ │ - * Closing “Unreviewed” tickets as “needsinfo” when the description is too
│ │ │ │ │ + * Closing «Unreviewed» tickets as «invalid», «worksforme», or «duplicate»,
│ │ │ │ │ + or «wontfix».
│ │ │ │ │ + * Closing «Unreviewed» tickets as «needsinfo» when the description is too
│ │ │ │ │ sparse to be actionable, or when they’re feature requests requiring a
│ │ │ │ │ discussion on the _D_j_a_n_g_o_ _F_o_r_u_m or _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s.
│ │ │ │ │ - * Correcting the “Needs tests”, “Needs documentation”, or “Has patch” flags
│ │ │ │ │ + * Correcting the «Needs tests», «Needs documentation», or «Has patch» flags
│ │ │ │ │ for tickets where they are incorrectly set.
│ │ │ │ │ - * Setting the “_E_a_s_y_ _p_i_c_k_i_n_g_s” flag for tickets that are small and
│ │ │ │ │ + * Setting the «_E_a_s_y_ _p_i_c_k_i_n_g_s» flag for tickets that are small and
│ │ │ │ │ relatively straightforward.
│ │ │ │ │ * Set the ttyyppee of tickets that are still uncategorized.
│ │ │ │ │ * Checking that old tickets are still valid. If a ticket hasn’t seen any
│ │ │ │ │ activity in a long time, it’s possible that the problem has been fixed
│ │ │ │ │ but the ticket hasn’t yet been closed.
│ │ │ │ │ * Identifying trends and themes in the tickets. If there are a lot of bug
│ │ │ │ │ reports about a particular part of Django, it may indicate we should
│ │ │ │ │ consider refactoring that part of the code. If a trend is emerging, you
│ │ │ │ │ should raise it for discussion (referencing the relevant tickets) on the
│ │ │ │ │ _D_j_a_n_g_o_ _F_o_r_u_m or _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s.
│ │ │ │ │ * Verify if patches submitted by other users are correct. If they are
│ │ │ │ │ correct and also contain appropriate documentation and tests then move
│ │ │ │ │ - them to the “Ready for Checkin” stage. If they are not correct then leave
│ │ │ │ │ - a comment to explain why and set the corresponding flags (“Patch needs
│ │ │ │ │ - improvement”, “Needs tests” etc.).
│ │ │ │ │ -Note
│ │ │ │ │ + them to the «Ready for Checkin» stage. If they are not correct then leave
│ │ │ │ │ + a comment to explain why and set the corresponding flags («Patch needs
│ │ │ │ │ + improvement», «Needs tests» etc.).
│ │ │ │ │ +Nota
│ │ │ │ │ The _R_e_p_o_r_t_s_ _p_a_g_e contains links to many useful Trac queries, including several
│ │ │ │ │ that are useful for triaging tickets and reviewing patches as suggested above.
│ │ │ │ │ You can also find more _A_d_v_i_c_e_ _f_o_r_ _n_e_w_ _c_o_n_t_r_i_b_u_t_o_r_s.
│ │ │ │ │ However, we do ask the following of all general community members working in
│ │ │ │ │ the ticket database:
│ │ │ │ │ - * Please ddoonn?’tt promote your own tickets to “Ready for checkin”. You may
│ │ │ │ │ - mark other people’s tickets that you’ve reviewed as “Ready for checkin”,
│ │ │ │ │ + * Please ddoonn?’tt promote your own tickets to «Ready for checkin». You may
│ │ │ │ │ + mark other people’s tickets that you’ve reviewed as «Ready for checkin»,
│ │ │ │ │ but you should get at minimum one other community member to review a
│ │ │ │ │ patch that you submit.
│ │ │ │ │ * Please ddoonn?’tt reverse a decision without posting a message to the _D_j_a_n_g_o
│ │ │ │ │ _F_o_r_u_m or _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s to find consensus.
│ │ │ │ │ * If you’re unsure if you should be making a change, don’t make the change
│ │ │ │ │ but instead leave a comment with your concerns on the ticket, or post a
│ │ │ │ │ message to the _D_j_a_n_g_o_ _F_o_r_u_m or _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s. It’s okay to be unsure,
│ │ │ │ │ @@ -271,32 +271,32 @@
│ │ │ │ │ inadvertent side-effect. Here’s how you can determine this.
│ │ │ │ │ Begin by writing a regression test for Django’s test suite for the issue. For
│ │ │ │ │ example, we’ll pretend we’re debugging a regression in migrations. After you’ve
│ │ │ │ │ written the test and confirmed that it fails on the latest main branch, put it
│ │ │ │ │ in a separate file that you can run standalone. For our example, we’ll pretend
│ │ │ │ │ we created tests/migrations/test_regression.py, which can be run with:
│ │ │ │ │ $ ./runtests.py migrations.test_regression
│ │ │ │ │ -Next, we mark the current point in history as being “bad” since the test fails:
│ │ │ │ │ +Next, we mark the current point in history as being «bad» since the test fails:
│ │ │ │ │ $ git bisect bad
│ │ │ │ │ You need to start by "git bisect start"
│ │ │ │ │ Do you want me to do it for you [Y/n]? y
│ │ │ │ │ Now, we need to find a point in git history before the regression was
│ │ │ │ │ introduced (i.e. a point where the test passes). Use something like git
│ │ │ │ │ checkout HEAD~100 to check out an earlier revision (100 commits earlier, in
│ │ │ │ │ -this case). Check if the test fails. If so, mark that point as “bad” (git
│ │ │ │ │ +this case). Check if the test fails. If so, mark that point as «bad» (git
│ │ │ │ │ bisect bad), then check out an earlier revision and recheck. Once you find a
│ │ │ │ │ -revision where your test passes, mark it as “good”:
│ │ │ │ │ +revision where your test passes, mark it as «good»:
│ │ │ │ │ $ git bisect good
│ │ │ │ │ Bisecting: X revisions left to test after this (roughly Y steps)
│ │ │ │ │ ...
│ │ │ │ │ Now we’re ready for the fun part: using git bisect run to automate the rest of
│ │ │ │ │ the process:
│ │ │ │ │ $ git bisect run tests/runtests.py migrations.test_regression
│ │ │ │ │ You should see git bisect use a binary search to automatically checkout
│ │ │ │ │ -revisions between the good and bad commits until it finds the first “bad”
│ │ │ │ │ +revisions between the good and bad commits until it finds the first «bad»
│ │ │ │ │ commit where the test fails.
│ │ │ │ │ Now, report your results on the Trac ticket, and please include the regression
│ │ │ │ │ test as an attachment. When someone writes a fix for the bug, they’ll already
│ │ │ │ │ have your test as a starting point.
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ * _T_r_i_a_g_i_n_g_ _t_i_c_k_e_t_s
│ │ │ │ │ o _T_r_i_a_g_e_ _w_o_r_k_f_l_o_w
│ │ │ │ │ @@ -317,16 +317,16 @@
│ │ │ │ │ # _V_e_r_s_i_o_n
│ │ │ │ │ # _U_I_/_U_X
│ │ │ │ │ # _C_c
│ │ │ │ │ # _K_e_y_w_o_r_d_s
│ │ │ │ │ o _C_l_o_s_i_n_g_ _T_i_c_k_e_t_s
│ │ │ │ │ o _H_o_w_ _c_a_n_ _I_ _h_e_l_p_ _w_i_t_h_ _t_r_i_a_g_i_n_g_?
│ │ │ │ │ o _B_i_s_e_c_t_i_n_g_ _a_ _r_e_g_r_e_s_s_i_o_n
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _R_e_p_o_r_t_i_n_g_ _b_u_g_s_ _a_n_d_ _r_e_q_u_e_s_t_i_n_g_ _f_e_a_t_u_r_e_s
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _M_a_i_l_i_n_g_ _l_i_s_t_s_ _a_n_d_ _F_o_r_u_m
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/internals/contributing/writing-code/coding-style.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Coding style — Django 5.1b1 documentation
│ │ │ │ + Coding style — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -66,15 +67,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
f-strings should not be used for any string that may require translation,
│ │ │ │ including error and logging messages. In general format() is more
│ │ │ │ verbose, so the other formatting methods are preferred.
│ │ │ │
Don’t waste time doing unrelated refactoring of existing code to adjust the
│ │ │ │ formatting method.
│ │ │ │
│ │ │ │ -
Avoid use of “we” in comments, e.g. “Loop over” rather than “We loop over”.
│ │ │ │ +
Avoid use of «we» in comments, e.g. «Loop over» rather than «We loop over».
│ │ │ │
Use underscores, not camelCase, for variable, function and method names
│ │ │ │ (i.e. poll.get_unique_voters(), not poll.getUniqueVoters()).
│ │ │ │
Use InitialCaps for class names (or for factory functions that
│ │ │ │ return classes).
│ │ │ │
In docstrings, follow the style of existing docstrings and PEP 257.
│ │ │ │
In tests, use
│ │ │ │ assertRaisesMessage() and
│ │ │ │ @@ -193,15 +194,15 @@
│ │ │ │ expression matching.
│ │ │ │
Use assertIs(…,True/False) for testing
│ │ │ │ boolean values, rather than assertTrue() and
│ │ │ │ assertFalse(), so you can check the actual boolean
│ │ │ │ value, not the truthiness of the expression.
│ │ │ │
│ │ │ │
In test docstrings, state the expected behavior that each test demonstrates.
│ │ │ │ -Don’t include preambles such as “Tests that” or “Ensures that”.
│ │ │ │ +Don’t include preambles such as «Tests that» or «Ensures that».
│ │ │ │
Reserve ticket references for obscure issues where the ticket has additional
│ │ │ │ details that can’t be easily described in docstrings or comments. Include the
│ │ │ │ ticket number at the end of a sentence like this:
│ │ │ │
deftest_foo():
│ │ │ │ """
│ │ │ │ A test docstring looks like this (#123456).
│ │ │ │ """
│ │ │ │ @@ -553,15 +554,15 @@
│ │ │ │ silence the flake8 warning.
│ │ │ │
Systematically remove all trailing whitespaces from your code as those
│ │ │ │ add unnecessary bytes, add visual clutter to the patches and can also
│ │ │ │ occasionally cause unnecessary merge conflicts. Some IDE’s can be
│ │ │ │ configured to automatically remove them and most VCS tools can be set to
│ │ │ │ highlight them in diff outputs.
│ │ │ │
Please don’t put your name in the code you contribute. Our policy is to
│ │ │ │ -keep contributors’ names in the AUTHORS file distributed with Django
│ │ │ │ +keep contributors” names in the AUTHORS file distributed with Django
│ │ │ │ – not scattered throughout the codebase itself. Feel free to include a
│ │ │ │ change to the AUTHORS file in your patch if you make more than a
│ │ │ │ single trivial change.
We maintain a curated list of small issues suited to first-time or less
│ │ │ │ -experienced contributors, using the “easy pickings” filter. These are strongly
│ │ │ │ +experienced contributors, using the «easy pickings» filter. These are strongly
│ │ │ │ recommended for those contributors looking to make a contribution.
If you are fixing a really trivial issue, for example changing a word in the
│ │ │ │ documentation, the preferred way to provide the patch is using GitHub pull
│ │ │ │ requests without a Trac ticket.
In an open-source project with hundreds of contributors around the world, it’s
│ │ │ │ important to manage communication efficiently so that work doesn’t get
│ │ │ │ duplicated and contributors can be as effective as possible.
│ │ │ │ -
Hence, our policy is for contributors to “claim” tickets in order to let other
│ │ │ │ +
Hence, our policy is for contributors to «claim» tickets in order to let other
│ │ │ │ developers know that a particular bug or feature is being worked on.
│ │ │ │
If you have identified a contribution you want to make and you’re capable of
│ │ │ │ fixing it (as measured by your coding ability, knowledge of Django internals
│ │ │ │ and time availability), claim it by following these steps:
If a ticket for this issue doesn’t exist yet, create one in our
│ │ │ │ ticket tracker.
│ │ │ │
If a ticket for this issue already exists, make sure nobody else has
│ │ │ │ -claimed it. To do this, look at the “Owned by” section of the ticket.
│ │ │ │ -If it’s assigned to “nobody,” then it’s available to be claimed.
│ │ │ │ +claimed it. To do this, look at the «Owned by» section of the ticket.
│ │ │ │ +If it’s assigned to «nobody,» then it’s available to be claimed.
│ │ │ │ Otherwise, somebody else may be working on this ticket. Either find another
│ │ │ │ bug/feature to work on, or contact the developer working on the ticket to
│ │ │ │ offer your help. If a ticket has been assigned for weeks or months without
│ │ │ │ any activity, it’s probably safe to reassign it to yourself.
│ │ │ │ -
Log into your account, if you haven’t already, by clicking “GitHub Login”
│ │ │ │ -or “DjangoProject Login” in the upper left of the ticket page.
│ │ │ │ -
Claim the ticket by clicking the “assign to myself” radio button under
│ │ │ │ -“Action” near the bottom of the page, then click “Submit changes.”
│ │ │ │ +
Log into your account, if you haven’t already, by clicking «GitHub Login»
│ │ │ │ +or «DjangoProject Login» in the upper left of the ticket page.
│ │ │ │ +
Claim the ticket by clicking the «assign to myself» radio button under
│ │ │ │ +«Action» near the bottom of the page, then click «Submit changes.»
│ │ │ │
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
The Django software foundation requests that anyone contributing more than
│ │ │ │ a trivial patch to Django sign and submit a Contributor License
│ │ │ │ Agreement, this ensures that the Django Software Foundation has clear
│ │ │ │ license to all contributions allowing for a clear license for all users.
Once you’ve claimed a ticket, you have a responsibility to work on that ticket
│ │ │ │ in a reasonably timely fashion. If you don’t have time to work on it, either
│ │ │ │ unclaim it or don’t claim it in the first place!
│ │ │ │
If there’s no sign of progress on a particular claimed ticket for a week or
│ │ │ │ two, another developer may ask you to relinquish the ticket claim so that it’s
│ │ │ │ no longer monopolized and somebody else can claim it.
│ │ │ │
If you’ve claimed a ticket and it’s taking a long time (days or weeks) to code,
│ │ │ │ @@ -167,33 +168,33 @@
│ │ │ │
If you can’t send a pull request for some reason, you can also use patches in
│ │ │ │ Trac. When using this style, follow these guidelines.
│ │ │ │
│ │ │ │
Submit patches in the format returned by the gitdiff command.
│ │ │ │ -
Attach patches to a ticket in the ticket tracker, using the “attach
│ │ │ │ -file” button. Please don’t put the patch in the ticket description
│ │ │ │ +
Attach patches to a ticket in the ticket tracker, using the «attach
│ │ │ │ +file» button. Please don’t put the patch in the ticket description
│ │ │ │ or comment unless it’s a single line patch.
│ │ │ │
Name the patch file with a .diff extension; this will let the ticket
│ │ │ │ tracker apply correct syntax highlighting, which is quite helpful.
│ │ │ │
│ │ │ │
Regardless of the way you submit your work, follow these steps.
Check the “Has patch” box on the ticket and make sure the “Needs
│ │ │ │ -documentation”, “Needs tests”, and “Patch needs improvement” boxes aren’t
│ │ │ │ -checked. This makes the ticket appear in the “Patches needing review” queue
│ │ │ │ +
Check the «Has patch» box on the ticket and make sure the «Needs
│ │ │ │ +documentation», «Needs tests», and «Patch needs improvement» boxes aren’t
│ │ │ │ +checked. This makes the ticket appear in the «Patches needing review» queue
│ │ │ │ on the Development dashboard.
A “non-trivial” patch is one that is more than a small bug fix. It’s a patch
│ │ │ │ +
A «non-trivial» patch is one that is more than a small bug fix. It’s a patch
│ │ │ │ that introduces Django functionality and makes some sort of design decision.
│ │ │ │
If you provide a non-trivial patch, include evidence that alternatives have
│ │ │ │ been discussed on the Django Forum or django-developers list.
│ │ │ │
If you’re not sure whether your patch should be considered non-trivial, ask on
│ │ │ │ the ticket for opinions.
Finally, there are a couple of updates to Django’s documentation to make:
│ │ │ │
│ │ │ │
If the existing feature is documented, mark it deprecated in documentation
│ │ │ │ using the ..deprecated::A.B annotation. Include a short description
│ │ │ │ and a note about the upgrade path if applicable.
│ │ │ │
Add a description of the deprecated behavior, and the upgrade path if
│ │ │ │ applicable, to the current release notes (docs/releases/A.B.txt) under
│ │ │ │ -the “Features deprecated in A.B” heading.
Add an entry in the deprecation timeline (docs/internals/deprecation.txt)
│ │ │ │ under the appropriate version describing what code will be removed.
│ │ │ │
│ │ │ │
Once you have completed these steps, you are finished with the deprecation.
│ │ │ │ In each feature release, all
│ │ │ │ RemovedInDjangoXXWarnings matching the new version are removed.
│ │ │ │
│ │ │ │ @@ -296,23 +297,23 @@
│ │ │ │
For information on JavaScript patches, see the JavaScript patches
│ │ │ │ documentation.
Use this checklist to review a pull request. If you are reviewing a pull
│ │ │ │ request that is not your own and it passes all the criteria below, please set
│ │ │ │ -the “Triage Stage” on the corresponding Trac ticket to “Ready for checkin”.
│ │ │ │ +the «Triage Stage» on the corresponding Trac ticket to «Ready for checkin».
│ │ │ │ If you’ve left comments for improvement on the pull request, please tick the
│ │ │ │ appropriate flags on the Trac ticket based on the results of your review:
│ │ │ │ -“Patch needs improvement”, “Needs documentation”, and/or “Needs tests”. As time
│ │ │ │ -and interest permits, mergers do final reviews of “Ready for checkin” tickets
│ │ │ │ -and will either commit the patch or bump it back to “Accepted” if further works
│ │ │ │ +«Patch needs improvement», «Needs documentation», and/or «Needs tests». As time
│ │ │ │ +and interest permits, mergers do final reviews of «Ready for checkin» tickets
│ │ │ │ +and will either commit the patch or bump it back to «Accepted» if further works
│ │ │ │ need to be done. If you’re looking to become a merger, doing thorough reviews
│ │ │ │ of patches is a great way to earn trust.
│ │ │ │ -
Looking for a patch to review? Check out the “Patches needing review” section
│ │ │ │ +
Looking for a patch to review? Check out the «Patches needing review» section
│ │ │ │ of the Django Development Dashboard.
│ │ │ │ Looking to get your patch reviewed? Ensure the Trac flags on the ticket are
│ │ │ │ set so that the ticket appears in that queue.
Does the documentation build without any errors (makehtml, or
│ │ │ │ @@ -332,15 +333,15 @@
│ │ │ │ docs/releases/A.B.C.txt? Bug fixes that will be applied only to the main
│ │ │ │ branch don’t need a release note.
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,50 +1,50 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ SSuubbmmiittttiinngg ppaattcchheess_?¶ ************
│ │ │ │ │ We’re always grateful for patches to Django’s code. Indeed, bug reports with
│ │ │ │ │ associated patches will get fixed ffaarr more quickly than those without patches.
│ │ │ │ │ ********** TTyyppoo ffiixxeess aanndd ttrriivviiaall ddooccuummeennttaattiioonn cchhaannggeess_?¶ **********
│ │ │ │ │ If you are fixing a really trivial issue, for example changing a word in the
│ │ │ │ │ documentation, the preferred way to provide the patch is using GitHub pull
│ │ │ │ │ requests without a Trac ticket.
│ │ │ │ │ See the _W_o_r_k_i_n_g_ _w_i_t_h_ _G_i_t_ _a_n_d_ _G_i_t_H_u_b for more details on how to use pull
│ │ │ │ │ requests.
│ │ │ │ │ -********** ?“CCllaaiimmiinngg?” ttiicckkeettss_?¶ **********
│ │ │ │ │ +********** ?«CCllaaiimmiinngg?» ttiicckkeettss_?¶ **********
│ │ │ │ │ In an open-source project with hundreds of contributors around the world, it’s
│ │ │ │ │ important to manage communication efficiently so that work doesn’t get
│ │ │ │ │ duplicated and contributors can be as effective as possible.
│ │ │ │ │ -Hence, our policy is for contributors to “claim” tickets in order to let other
│ │ │ │ │ +Hence, our policy is for contributors to «claim» tickets in order to let other
│ │ │ │ │ developers know that a particular bug or feature is being worked on.
│ │ │ │ │ If you have identified a contribution you want to make and you’re capable of
│ │ │ │ │ fixing it (as measured by your coding ability, knowledge of Django internals
│ │ │ │ │ and time availability), claim it by following these steps:
│ │ │ │ │ * _L_o_g_i_n_ _u_s_i_n_g_ _y_o_u_r_ _G_i_t_H_u_b_ _a_c_c_o_u_n_t or _c_r_e_a_t_e_ _a_n_ _a_c_c_o_u_n_t in our ticket
│ │ │ │ │ system. If you have an account but have forgotten your password, you can
│ │ │ │ │ reset it using the _p_a_s_s_w_o_r_d_ _r_e_s_e_t_ _p_a_g_e.
│ │ │ │ │ * If a ticket for this issue doesn’t exist yet, create one in our _t_i_c_k_e_t
│ │ │ │ │ _t_r_a_c_k_e_r.
│ │ │ │ │ * If a ticket for this issue already exists, make sure nobody else has
│ │ │ │ │ - claimed it. To do this, look at the “Owned by” section of the ticket. If
│ │ │ │ │ - it’s assigned to “nobody,” then it’s available to be claimed. Otherwise,
│ │ │ │ │ + claimed it. To do this, look at the «Owned by» section of the ticket. If
│ │ │ │ │ + it’s assigned to «nobody,» then it’s available to be claimed. Otherwise,
│ │ │ │ │ somebody else may be working on this ticket. Either find another bug/
│ │ │ │ │ feature to work on, or contact the developer working on the ticket to
│ │ │ │ │ offer your help. If a ticket has been assigned for weeks or months
│ │ │ │ │ without any activity, it’s probably safe to reassign it to yourself.
│ │ │ │ │ - * Log into your account, if you haven’t already, by clicking “GitHub Login”
│ │ │ │ │ - or “DjangoProject Login” in the upper left of the ticket page.
│ │ │ │ │ - * Claim the ticket by clicking the “assign to myself” radio button under
│ │ │ │ │ - “Action” near the bottom of the page, then click “Submit changes.”
│ │ │ │ │ -Note
│ │ │ │ │ + * Log into your account, if you haven’t already, by clicking «GitHub Login»
│ │ │ │ │ + or «DjangoProject Login» in the upper left of the ticket page.
│ │ │ │ │ + * Claim the ticket by clicking the «assign to myself» radio button under
│ │ │ │ │ + «Action» near the bottom of the page, then click «Submit changes.»
│ │ │ │ │ +Nota
│ │ │ │ │ The Django software foundation requests that anyone contributing more than a
│ │ │ │ │ trivial patch to Django sign and submit a _C_o_n_t_r_i_b_u_t_o_r_ _L_i_c_e_n_s_e_ _A_g_r_e_e_m_e_n_t, this
│ │ │ │ │ ensures that the Django Software Foundation has clear license to all
│ │ │ │ │ contributions allowing for a clear license for all users.
│ │ │ │ │ -******** TTiicckkeett ccllaaiimmeerrss?’ rreessppoonnssiibbiilliittyy_?¶ ********
│ │ │ │ │ +******** TTiicckkeett ccllaaiimmeerrss?” rreessppoonnssiibbiilliittyy_?¶ ********
│ │ │ │ │ Once you’ve claimed a ticket, you have a responsibility to work on that ticket
│ │ │ │ │ in a reasonably timely fashion. If you don’t have time to work on it, either
│ │ │ │ │ unclaim it or don’t claim it in the first place!
│ │ │ │ │ If there’s no sign of progress on a particular claimed ticket for a week or
│ │ │ │ │ two, another developer may ask you to relinquish the ticket claim so that it’s
│ │ │ │ │ no longer monopolized and somebody else can claim it.
│ │ │ │ │ If you’ve claimed a ticket and it’s taking a long time (days or weeks) to code,
│ │ │ │ │ @@ -73,28 +73,28 @@
│ │ │ │ │ behavior of an existing feature, the patch should also contain
│ │ │ │ │ documentation.
│ │ │ │ │ When you think your work is ready to be reviewed, send _a_ _G_i_t_H_u_b_ _p_u_l_l_ _r_e_q_u_e_s_t.
│ │ │ │ │ Please review the patch yourself using our _p_a_t_c_h_ _r_e_v_i_e_w_ _c_h_e_c_k_l_i_s_t first.
│ │ │ │ │ If you can’t send a pull request for some reason, you can also use patches in
│ │ │ │ │ Trac. When using this style, follow these guidelines.
│ │ │ │ │ * Submit patches in the format returned by the git diff command.
│ │ │ │ │ - * Attach patches to a ticket in the _t_i_c_k_e_t_ _t_r_a_c_k_e_r, using the “attach file”
│ │ │ │ │ + * Attach patches to a ticket in the _t_i_c_k_e_t_ _t_r_a_c_k_e_r, using the «attach file»
│ │ │ │ │ button. Please ddoonn?’tt put the patch in the ticket description or comment
│ │ │ │ │ unless it’s a single line patch.
│ │ │ │ │ * Name the patch file with a .diff extension; this will let the ticket
│ │ │ │ │ tracker apply correct syntax highlighting, which is quite helpful.
│ │ │ │ │ Regardless of the way you submit your work, follow these steps.
│ │ │ │ │ * Make sure your code fulfills the requirements in our _p_a_t_c_h_ _r_e_v_i_e_w
│ │ │ │ │ _c_h_e_c_k_l_i_s_t.
│ │ │ │ │ - * Check the “Has patch” box on the ticket and make sure the “Needs
│ │ │ │ │ - documentation”, “Needs tests”, and “Patch needs improvement” boxes aren’t
│ │ │ │ │ - checked. This makes the ticket appear in the “Patches needing review”
│ │ │ │ │ + * Check the «Has patch» box on the ticket and make sure the «Needs
│ │ │ │ │ + documentation», «Needs tests», and «Patch needs improvement» boxes aren’t
│ │ │ │ │ + checked. This makes the ticket appear in the «Patches needing review»
│ │ │ │ │ queue on the _D_e_v_e_l_o_p_m_e_n_t_ _d_a_s_h_b_o_a_r_d.
│ │ │ │ │ ********** NNoonn--ttrriivviiaall ppaattcchheess_?¶ **********
│ │ │ │ │ -A “non-trivial” patch is one that is more than a small bug fix. It’s a patch
│ │ │ │ │ +A «non-trivial» patch is one that is more than a small bug fix. It’s a patch
│ │ │ │ │ that introduces Django functionality and makes some sort of design decision.
│ │ │ │ │ If you provide a non-trivial patch, include evidence that alternatives have
│ │ │ │ │ been discussed on the _D_j_a_n_g_o_ _F_o_r_u_m or _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s list.
│ │ │ │ │ If you’re not sure whether your patch should be considered non-trivial, ask on
│ │ │ │ │ the ticket for opinions.
│ │ │ │ │ ********** DDeepprreeccaattiinngg aa ffeeaattuurree_?¶ **********
│ │ │ │ │ There are a couple of reasons that code in Django might be deprecated:
│ │ │ │ │ @@ -162,35 +162,35 @@
│ │ │ │ │ ...
│ │ │ │ │ Finally, there are a couple of updates to Django’s documentation to make:
│ │ │ │ │ 1. If the existing feature is documented, mark it deprecated in
│ │ │ │ │ documentation using the .. deprecated:: A.B annotation. Include a short
│ │ │ │ │ description and a note about the upgrade path if applicable.
│ │ │ │ │ 2. Add a description of the deprecated behavior, and the upgrade path if
│ │ │ │ │ applicable, to the current release notes (docs/releases/A.B.txt) under
│ │ │ │ │ - the “Features deprecated in A.B” heading.
│ │ │ │ │ + the «Features deprecated in A.B» heading.
│ │ │ │ │ 3. Add an entry in the deprecation timeline (docs/internals/deprecation.txt)
│ │ │ │ │ under the appropriate version describing what code will be removed.
│ │ │ │ │ Once you have completed these steps, you are finished with the deprecation. In
│ │ │ │ │ each _f_e_a_t_u_r_e_ _r_e_l_e_a_s_e, all RemovedInDjangoXXWarnings matching the new version
│ │ │ │ │ are removed.
│ │ │ │ │ ********** JJaavvaaSSccrriipptt ppaattcchheess_?¶ **********
│ │ │ │ │ For information on JavaScript patches, see the _J_a_v_a_S_c_r_i_p_t_ _p_a_t_c_h_e_s
│ │ │ │ │ documentation.
│ │ │ │ │ ********** PPaattcchh rreevviieeww cchheecckklliisstt_?¶ **********
│ │ │ │ │ Use this checklist to review a pull request. If you are reviewing a pull
│ │ │ │ │ request that is not your own and it passes all the criteria below, please set
│ │ │ │ │ -the “Triage Stage” on the corresponding Trac ticket to “Ready for checkin”. If
│ │ │ │ │ +the «Triage Stage» on the corresponding Trac ticket to «Ready for checkin». If
│ │ │ │ │ you’ve left comments for improvement on the pull request, please tick the
│ │ │ │ │ appropriate flags on the Trac ticket based on the results of your review:
│ │ │ │ │ -“Patch needs improvement”, “Needs documentation”, and/or “Needs tests”. As time
│ │ │ │ │ -and interest permits, mergers do final reviews of “Ready for checkin” tickets
│ │ │ │ │ -and will either commit the patch or bump it back to “Accepted” if further works
│ │ │ │ │ +«Patch needs improvement», «Needs documentation», and/or «Needs tests». As time
│ │ │ │ │ +and interest permits, mergers do final reviews of «Ready for checkin» tickets
│ │ │ │ │ +and will either commit the patch or bump it back to «Accepted» if further works
│ │ │ │ │ need to be done. If you’re looking to become a merger, doing thorough reviews
│ │ │ │ │ of patches is a great way to earn trust.
│ │ │ │ │ -Looking for a patch to review? Check out the “Patches needing review” section
│ │ │ │ │ +Looking for a patch to review? Check out the «Patches needing review» section
│ │ │ │ │ of the _D_j_a_n_g_o_ _D_e_v_e_l_o_p_m_e_n_t_ _D_a_s_h_b_o_a_r_d. Looking to get your patch reviewed? Ensure
│ │ │ │ │ the Trac flags on the ticket are set so that the ticket appears in that queue.
│ │ │ │ │ ******** DDooccuummeennttaattiioonn_?¶ ********
│ │ │ │ │ * Does the documentation build without any errors (make html, or make.bat
│ │ │ │ │ html on Windows, from the docs directory)?
│ │ │ │ │ * Does the documentation follow the writing style guidelines in _W_r_i_t_i_n_g
│ │ │ │ │ _d_o_c_u_m_e_n_t_a_t_i_o_n?
│ │ │ │ │ @@ -198,15 +198,15 @@
│ │ │ │ │ ******** BBuuggss_?¶ ********
│ │ │ │ │ * Is there a proper regression test (the test should fail before the fix is
│ │ │ │ │ applied)?
│ │ │ │ │ * If it’s a bug that _q_u_a_l_i_f_i_e_s_ _f_o_r_ _a_ _b_a_c_k_p_o_r_t to the stable version of
│ │ │ │ │ Django, is there a release note in docs/releases/A.B.C.txt? Bug fixes
│ │ │ │ │ that will be applied only to the main branch don’t need a release note.
│ │ │ │ │ ******** NNeeww FFeeaattuurreess_?¶ ********
│ │ │ │ │ - * Are there tests to “exercise” all of the new code?
│ │ │ │ │ + * Are there tests to «exercise» all of the new code?
│ │ │ │ │ * Is there a release note in docs/releases/A.B.txt?
│ │ │ │ │ * Is there documentation for the feature and is it _a_n_n_o_t_a_t_e_d_ _a_p_p_r_o_p_r_i_a_t_e_l_y
│ │ │ │ │ with .. versionadded:: A.B or .. versionchanged:: A.B?
│ │ │ │ │ ******** DDeepprreeccaattiinngg aa ffeeaattuurree_?¶ ********
│ │ │ │ │ See the _D_e_p_r_e_c_a_t_i_n_g_ _a_ _f_e_a_t_u_r_e guide.
│ │ │ │ │ ******** AAllll ccooddee cchhaannggeess_?¶ ********
│ │ │ │ │ * Does the _c_o_d_i_n_g_ _s_t_y_l_e conform to our guidelines? Are there any black,
│ │ │ │ │ @@ -219,30 +219,30 @@
│ │ │ │ │ * Is the pull request a single squashed commit with a message that follows
│ │ │ │ │ our _c_o_m_m_i_t_ _m_e_s_s_a_g_e_ _f_o_r_m_a_t?
│ │ │ │ │ * Are you the patch author and a new contributor? Please add yourself to
│ │ │ │ │ the _A_U_T_H_O_R_S file and submit a _C_o_n_t_r_i_b_u_t_o_r_ _L_i_c_e_n_s_e_ _A_g_r_e_e_m_e_n_t.
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ * _S_u_b_m_i_t_t_i_n_g_ _p_a_t_c_h_e_s
│ │ │ │ │ o _T_y_p_o_ _f_i_x_e_s_ _a_n_d_ _t_r_i_v_i_a_l_ _d_o_c_u_m_e_n_t_a_t_i_o_n_ _c_h_a_n_g_e_s
│ │ │ │ │ - o _“_C_l_a_i_m_i_n_g_”_ _t_i_c_k_e_t_s
│ │ │ │ │ - # _T_i_c_k_e_t_ _c_l_a_i_m_e_r_s_’_ _r_e_s_p_o_n_s_i_b_i_l_i_t_y
│ │ │ │ │ + o _«_C_l_a_i_m_i_n_g_»_ _t_i_c_k_e_t_s
│ │ │ │ │ + # _T_i_c_k_e_t_ _c_l_a_i_m_e_r_s_”_ _r_e_s_p_o_n_s_i_b_i_l_i_t_y
│ │ │ │ │ # _W_h_i_c_h_ _t_i_c_k_e_t_s_ _s_h_o_u_l_d_ _b_e_ _c_l_a_i_m_e_d_?
│ │ │ │ │ o _P_a_t_c_h_ _s_t_y_l_e
│ │ │ │ │ o _N_o_n_-_t_r_i_v_i_a_l_ _p_a_t_c_h_e_s
│ │ │ │ │ o _D_e_p_r_e_c_a_t_i_n_g_ _a_ _f_e_a_t_u_r_e
│ │ │ │ │ o _J_a_v_a_S_c_r_i_p_t_ _p_a_t_c_h_e_s
│ │ │ │ │ o _P_a_t_c_h_ _r_e_v_i_e_w_ _c_h_e_c_k_l_i_s_t
│ │ │ │ │ # _D_o_c_u_m_e_n_t_a_t_i_o_n
│ │ │ │ │ # _B_u_g_s
│ │ │ │ │ # _N_e_w_ _F_e_a_t_u_r_e_s
│ │ │ │ │ # _D_e_p_r_e_c_a_t_i_n_g_ _a_ _f_e_a_t_u_r_e
│ │ │ │ │ # _A_l_l_ _c_o_d_e_ _c_h_a_n_g_e_s
│ │ │ │ │ # _A_l_l_ _t_i_c_k_e_t_s
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _C_o_n_t_r_i_b_u_t_i_n_g_ _c_o_d_e
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _U_n_i_t_ _t_e_s_t_s
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/internals/contributing/writing-code/unit-tests.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Unit tests — Django 5.1b1 documentation
│ │ │ │ + Unit tests — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -66,15 +67,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Note that user.name should be your real name, not your GitHub nick. GitHub
│ │ │ │ should know the email you use in the user.email field, as this will be
│ │ │ │ used to associate your commits with your GitHub account.
When you have created your GitHub account, with the nick “GitHub_nick”, and
│ │ │ │ +
When you have created your GitHub account, with the nick «GitHub_nick», and
│ │ │ │ forked Django’s repository,
│ │ │ │ create a local copy of your fork:
This will create a new directory “django”, containing a clone of your GitHub
│ │ │ │ +
This will create a new directory «django», containing a clone of your GitHub
│ │ │ │ repository. The rest of the git commands on this page need to be run within the
│ │ │ │ cloned directory, so switch to it now:
│ │ │ │
cddjango
│ │ │ │
│ │ │ │
│ │ │ │ -
Your GitHub repository will be called “origin” in Git.
│ │ │ │ -
You should also set up django/django as an “upstream” remote (that is, tell
│ │ │ │ +
Your GitHub repository will be called «origin» in Git.
│ │ │ │ +
You should also set up django/django as an «upstream» remote (that is, tell
│ │ │ │ git that the reference Django repository was the source of your fork of it):
When you go to your GitHub page, you will notice a new branch has been created.
│ │ │ │
If you are working on a Trac ticket, you should mention in the ticket that
│ │ │ │ your work is available from branch ticket_xxxxx of your GitHub repo. Include a
│ │ │ │ link to your branch.
│ │ │ │ -
Note that the above branch is called a “topic branch” in Git parlance. You are
│ │ │ │ +
Note that the above branch is called a «topic branch» in Git parlance. You are
│ │ │ │ free to rewrite the history of this branch, by using gitrebase for
│ │ │ │ example. Other people shouldn’t base their work on such a branch, because
│ │ │ │ their clone would become corrupt when you edit commits.
│ │ │ │ -
There are also “public branches”. These are branches other people are supposed
│ │ │ │ +
There are also «public branches». These are branches other people are supposed
│ │ │ │ to fork, so the history of these branches should never change. Good examples
│ │ │ │ of public branches are the main and stable/A.B.x branches in the
│ │ │ │ django/django repository.
│ │ │ │
When you think your work is ready to be pulled into Django, you should create
│ │ │ │ a pull request at GitHub. A good pull request means:
│ │ │ │
│ │ │ │
commits with one logical change in each, following the
│ │ │ │ @@ -184,40 +185,40 @@
│ │ │ │ wrapped at 72 characters thereafter – see the committing guidelines for more details,
│ │ │ │
documentation and tests, if needed – actually tests are always needed,
│ │ │ │ except for documentation changes.
│ │ │ │
│ │ │ │
The test suite must pass and the documentation must build without warnings.
│ │ │ │
Once you have created your pull request, you should add a comment in the
│ │ │ │ related Trac ticket explaining what you’ve done. In particular, you should note
│ │ │ │ -the environment in which you ran the tests, for instance: “all tests pass
│ │ │ │ -under SQLite and MySQL”.
│ │ │ │ +the environment in which you ran the tests, for instance: «all tests pass
│ │ │ │ +under SQLite and MySQL».
│ │ │ │
Pull requests at GitHub have only two states: open and closed. The merger who
│ │ │ │ will deal with your pull request has only two options: merge it or close it.
│ │ │ │ For this reason, it isn’t useful to make a pull request until the code is ready
│ │ │ │ for merging – or sufficiently close that a merger will finish it themselves.
In the example above, you created two commits, the “Fixed ticket_xxxxx” commit
│ │ │ │ -and “Added two more tests” commit.
│ │ │ │ +
In the example above, you created two commits, the «Fixed ticket_xxxxx» commit
│ │ │ │ +and «Added two more tests» commit.
│ │ │ │
We do not want to have the entire history of your working process in your
│ │ │ │ -repository. Your commit “Added two more tests” would be unhelpful noise.
│ │ │ │ +repository. Your commit «Added two more tests» would be unhelpful noise.
│ │ │ │ Instead, we would rather only have one commit containing all your work.
│ │ │ │
To rework the history of your branch you can squash the commits into one by
│ │ │ │ using interactive rebase:
│ │ │ │
gitrebase-iHEAD~2
│ │ │ │
│ │ │ │
│ │ │ │
The HEAD~2 above is shorthand for two latest commits. The above command
│ │ │ │ -will open an editor showing the two commits, prefixed with the word “pick”.
│ │ │ │ -
Change “pick” on the second line to “squash” instead. This will keep the
│ │ │ │ +will open an editor showing the two commits, prefixed with the word «pick».
│ │ │ │ +
Change «pick» on the second line to «squash» instead. This will keep the
│ │ │ │ first commit, and squash the second commit into the first one. Save and quit
│ │ │ │ the editor. A second editor window should open, so you can reword the
│ │ │ │ commit message for the commit now that it includes both your steps.
│ │ │ │ -
You can also use the “edit” option in rebase. This way you can change a single
│ │ │ │ +
You can also use the «edit» option in rebase. This way you can change a single
│ │ │ │ commit, for example to fix a typo in a docstring:
│ │ │ │
gitrebase-iHEAD~3
│ │ │ │ # Choose edit, pick, pick for the commits
│ │ │ │ # Now you are able to rework the commit (use git add normally to add changes)
│ │ │ │ # When finished, commit work with "--amend" and continue
│ │ │ │ gitcommit--amend
│ │ │ │ # Reword the commit message if needed
│ │ │ │ @@ -342,37 +343,37 @@
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ WWoorrkkiinngg wwiitthh GGiitt aanndd GGiittHHuubb_?¶ ************
│ │ │ │ │ This section explains how the community can contribute code to Django via pull
│ │ │ │ │ requests. If you’re interested in how _m_e_r_g_e_r_s handle them, see _C_o_m_m_i_t_t_i_n_g_ _c_o_d_e.
│ │ │ │ │ Below, we are going to show how to create a GitHub pull request containing the
│ │ │ │ │ changes for Trac ticket #xxxxx. By creating a fully-ready pull request, you
│ │ │ │ │ @@ -19,23 +19,23 @@
│ │ │ │ │ email:
│ │ │ │ │ $ git config --global user.name "Your Real Name"
│ │ │ │ │ $ git config --global user.email "you@email.com"
│ │ │ │ │ Note that user.name should be your real name, not your GitHub nick. GitHub
│ │ │ │ │ should know the email you use in the user.email field, as this will be used to
│ │ │ │ │ associate your commits with your GitHub account.
│ │ │ │ │ ********** SSeettttiinngg uupp llooccaall rreeppoossiittoorryy_?¶ **********
│ │ │ │ │ -When you have created your GitHub account, with the nick “GitHub_nick”, and
│ │ │ │ │ +When you have created your GitHub account, with the nick «GitHub_nick», and
│ │ │ │ │ _f_o_r_k_e_d_ _D_j_a_n_g_o_’_s_ _r_e_p_o_s_i_t_o_r_y, create a local copy of your fork:
│ │ │ │ │ git clone https://github.com/GitHub_nick/django.git
│ │ │ │ │ -This will create a new directory “django”, containing a clone of your GitHub
│ │ │ │ │ +This will create a new directory «django», containing a clone of your GitHub
│ │ │ │ │ repository. The rest of the git commands on this page need to be run within the
│ │ │ │ │ cloned directory, so switch to it now:
│ │ │ │ │ cd django
│ │ │ │ │ -Your GitHub repository will be called “origin” in Git.
│ │ │ │ │ -You should also set up django/django as an “upstream” remote (that is, tell git
│ │ │ │ │ +Your GitHub repository will be called «origin» in Git.
│ │ │ │ │ +You should also set up django/django as an «upstream» remote (that is, tell git
│ │ │ │ │ that the reference Django repository was the source of your fork of it):
│ │ │ │ │ git remote add upstream https://github.com/django/django.git
│ │ │ │ │ git fetch upstream
│ │ │ │ │ You can add other remotes similarly, for example:
│ │ │ │ │ git remote add akaariai https://github.com/akaariai/django.git
│ │ │ │ │ ********** WWoorrkkiinngg oonn aa ttiicckkeett_?¶ **********
│ │ │ │ │ When working on a ticket, create a new branch for the work, and base that work
│ │ │ │ │ @@ -56,55 +56,55 @@
│ │ │ │ │ ******** PPuubblliisshhiinngg wwoorrkk_?¶ ********
│ │ │ │ │ You can publish your work on GitHub by running:
│ │ │ │ │ git push origin ticket_xxxxx
│ │ │ │ │ When you go to your GitHub page, you will notice a new branch has been created.
│ │ │ │ │ If you are working on a Trac ticket, you should mention in the ticket that your
│ │ │ │ │ work is available from branch ticket_xxxxx of your GitHub repo. Include a link
│ │ │ │ │ to your branch.
│ │ │ │ │ -Note that the above branch is called a “topic branch” in Git parlance. You are
│ │ │ │ │ +Note that the above branch is called a «topic branch» in Git parlance. You are
│ │ │ │ │ free to rewrite the history of this branch, by using git rebase for example.
│ │ │ │ │ Other people shouldn’t base their work on such a branch, because their clone
│ │ │ │ │ would become corrupt when you edit commits.
│ │ │ │ │ -There are also “public branches”. These are branches other people are supposed
│ │ │ │ │ +There are also «public branches». These are branches other people are supposed
│ │ │ │ │ to fork, so the history of these branches should never change. Good examples of
│ │ │ │ │ public branches are the main and stable/A.B.x branches in the django/django
│ │ │ │ │ repository.
│ │ │ │ │ When you think your work is ready to be pulled into Django, you should create a
│ │ │ │ │ pull request at GitHub. A good pull request means:
│ │ │ │ │ * commits with one logical change in each, following the _c_o_d_i_n_g_ _s_t_y_l_e,
│ │ │ │ │ * well-formed messages for each commit: a summary line and then paragraphs
│ │ │ │ │ wrapped at 72 characters thereafter – see the _c_o_m_m_i_t_t_i_n_g_ _g_u_i_d_e_l_i_n_e_s for
│ │ │ │ │ more details,
│ │ │ │ │ * documentation and tests, if needed – actually tests are always needed,
│ │ │ │ │ except for documentation changes.
│ │ │ │ │ The test suite must pass and the documentation must build without warnings.
│ │ │ │ │ Once you have created your pull request, you should add a comment in the
│ │ │ │ │ related Trac ticket explaining what you’ve done. In particular, you should note
│ │ │ │ │ -the environment in which you ran the tests, for instance: “all tests pass under
│ │ │ │ │ -SQLite and MySQL”.
│ │ │ │ │ +the environment in which you ran the tests, for instance: «all tests pass under
│ │ │ │ │ +SQLite and MySQL».
│ │ │ │ │ Pull requests at GitHub have only two states: open and closed. The merger who
│ │ │ │ │ will deal with your pull request has only two options: merge it or close it.
│ │ │ │ │ For this reason, it isn’t useful to make a pull request until the code is ready
│ │ │ │ │ for merging – or sufficiently close that a merger will finish it themselves.
│ │ │ │ │ ******** RReebbaassiinngg bbrraanncchheess_?¶ ********
│ │ │ │ │ -In the example above, you created two commits, the “Fixed ticket_xxxxx” commit
│ │ │ │ │ -and “Added two more tests” commit.
│ │ │ │ │ +In the example above, you created two commits, the «Fixed ticket_xxxxx» commit
│ │ │ │ │ +and «Added two more tests» commit.
│ │ │ │ │ We do not want to have the entire history of your working process in your
│ │ │ │ │ -repository. Your commit “Added two more tests” would be unhelpful noise.
│ │ │ │ │ +repository. Your commit «Added two more tests» would be unhelpful noise.
│ │ │ │ │ Instead, we would rather only have one commit containing all your work.
│ │ │ │ │ To rework the history of your branch you can squash the commits into one by
│ │ │ │ │ using interactive rebase:
│ │ │ │ │ git rebase -i HEAD~2
│ │ │ │ │ The HEAD~2 above is shorthand for two latest commits. The above command will
│ │ │ │ │ -open an editor showing the two commits, prefixed with the word “pick”.
│ │ │ │ │ -Change “pick” on the second line to “squash” instead. This will keep the first
│ │ │ │ │ +open an editor showing the two commits, prefixed with the word «pick».
│ │ │ │ │ +Change «pick» on the second line to «squash» instead. This will keep the first
│ │ │ │ │ commit, and squash the second commit into the first one. Save and quit the
│ │ │ │ │ editor. A second editor window should open, so you can reword the commit
│ │ │ │ │ message for the commit now that it includes both your steps.
│ │ │ │ │ -You can also use the “edit” option in rebase. This way you can change a single
│ │ │ │ │ +You can also use the «edit» option in rebase. This way you can change a single
│ │ │ │ │ commit, for example to fix a typo in a docstring:
│ │ │ │ │ git rebase -i HEAD~3
│ │ │ │ │ # Choose edit, pick, pick for the commits
│ │ │ │ │ # Now you are able to rework the commit (use git add normally to add changes)
│ │ │ │ │ # When finished, commit work with "--amend" and continue
│ │ │ │ │ git commit --amend
│ │ │ │ │ # Reword the commit message if needed
│ │ │ │ │ @@ -180,16 +180,16 @@
│ │ │ │ │ o _W_o_r_k_i_n_g_ _o_n_ _a_ _t_i_c_k_e_t
│ │ │ │ │ # _P_u_b_l_i_s_h_i_n_g_ _w_o_r_k
│ │ │ │ │ # _R_e_b_a_s_i_n_g_ _b_r_a_n_c_h_e_s
│ │ │ │ │ # _A_f_t_e_r_ _u_p_s_t_r_e_a_m_ _h_a_s_ _c_h_a_n_g_e_d
│ │ │ │ │ # _A_f_t_e_r_ _r_e_v_i_e_w
│ │ │ │ │ o _W_o_r_k_i_n_g_ _o_n_ _a_ _p_a_t_c_h
│ │ │ │ │ o _S_u_m_m_a_r_y
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _U_n_i_t_ _t_e_s_t_s
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _C_o_d_i_n_g_ _s_t_y_l_e
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/internals/contributing/writing-documentation.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Writing documentation — Django 5.1b1 documentation
│ │ │ │ + Writing documentation — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -66,15 +67,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Links in documentation can become broken or changed such that they are no
│ │ │ │ longer the canonical link. Sphinx provides a builder that can check whether the
│ │ │ │ links in the documentation are working. From the docs directory, run make
│ │ │ │ linkcheck. Output is printed to the terminal, but can also be found in
│ │ │ │ _build/linkcheck/output.txt and _build/linkcheck/output.json.
│ │ │ │ -
Entries that have a status of “working” are fine, those that are “unchecked” or
│ │ │ │ -“ignored” have been skipped because they either cannot be checked or have
│ │ │ │ +
Entries that have a status of «working» are fine, those that are «unchecked» or
│ │ │ │ +«ignored» have been skipped because they either cannot be checked or have
│ │ │ │ matched ignore rules in the configuration.
│ │ │ │ -
Entries that have a status of “broken” need to be fixed. Those that have a
│ │ │ │ -status of “redirected” may need to be updated to point to the canonical
│ │ │ │ +
Entries that have a status of «broken» need to be fixed. Those that have a
│ │ │ │ +status of «redirected» may need to be updated to point to the canonical
│ │ │ │ location, e.g. the scheme has changed http:// → https://. In certain
│ │ │ │ -cases, we do not want to update a “redirected” link, e.g. a rewrite to always
│ │ │ │ +cases, we do not want to update a «redirected» link, e.g. a rewrite to always
│ │ │ │ point to the latest or stable version of the documentation, e.g. /en/stable/ →
│ │ │ │ /en/3.2/.
When using pronouns in reference to a hypothetical person, such as “a user with
│ │ │ │ -a session cookie”, gender-neutral pronouns (they/their/them) should be used.
│ │ │ │ +
When using pronouns in reference to a hypothetical person, such as «a user with
│ │ │ │ +a session cookie», gender-neutral pronouns (they/their/them) should be used.
│ │ │ │ Instead of:
│ │ │ │
│ │ │ │
he or she… use they.
│ │ │ │
him or her… use them.
│ │ │ │
his or her… use their.
│ │ │ │
his or hers… use theirs.
│ │ │ │
himself or herself… use themselves.
│ │ │ │
│ │ │ │
Try to avoid using words that minimize the difficulty involved in a task or
│ │ │ │ -operation, such as “easily”, “simply”, “just”, “merely”, “straightforward”, and
│ │ │ │ +operation, such as «easily», «simply», «just», «merely», «straightforward», and
│ │ │ │ so on. People’s experience may not match your expectations, and they may become
│ │ │ │ -frustrated when they do not find a step as “straightforward” or “simple” as it
│ │ │ │ +frustrated when they do not find a step as «straightforward» or «simple» as it
│ │ │ │ is implied to be.
Here are some style guidelines on commonly used terms throughout the
│ │ │ │ documentation:
│ │ │ │
│ │ │ │
Django – when referring to the framework, capitalize Django. It is
│ │ │ │ lowercase only in Python code and in the djangoproject.com logo.
│ │ │ │
email – no hyphen.
│ │ │ │ -
HTTP – the expected pronunciation is “Aitch Tee Tee Pee” and therefore
│ │ │ │ -should be preceded by “an” and not “a”.
│ │ │ │ +
HTTP – the expected pronunciation is «Aitch Tee Tee Pee» and therefore
│ │ │ │ +should be preceded by «an» and not «a».
│ │ │ │
MySQL, PostgreSQL, SQLite
│ │ │ │
SQL – when referring to SQL, the expected pronunciation should be
│ │ │ │ -“Ess Queue Ell” and not “sequel”. Thus in a phrase like “Returns an
│ │ │ │ -SQL expression”, “SQL” should be preceded by “an” and not “a”.
│ │ │ │ +«Ess Queue Ell» and not «sequel». Thus in a phrase like «Returns an
│ │ │ │ +SQL expression», «SQL» should be preceded by «an» and not «a».
│ │ │ │
Python – when referring to the language, capitalize Python.
│ │ │ │
realize, customize, initialize, etc. – use the American
│ │ │ │ -“ize” suffix, not “ise.”
│ │ │ │ +«ize» suffix, not «ise.»
│ │ │ │
subclass – it’s a single word without a hyphen, both as a verb
│ │ │ │ -(“subclass that model”) and as a noun (“create a subclass”).
│ │ │ │ +(«subclass that model») and as a noun («create a subclass»).
│ │ │ │
These guidelines regulate the format of our reST (reStructuredText)
│ │ │ │ documentation:
│ │ │ │ @@ -340,20 +341,20 @@
│ │ │ │
Isn’t nearly as helpful as:
│ │ │ │
Add :mod:`django.contrib.auth` to your :setting:`INSTALLED_APPS`...
│ │ │ │
│ │ │ │
│ │ │ │
This is because Sphinx will generate proper links for the latter, which
│ │ │ │ greatly helps readers.
│ │ │ │
You can prefix the target with a ~ (that’s a tilde) to get only the
│ │ │ │ -“last bit” of that path. So :mod:`~django.contrib.auth` will
│ │ │ │ -display a link with the title “auth”.
│ │ │ │ +«last bit» of that path. So :mod:`~django.contrib.auth` will
│ │ │ │ +display a link with the title «auth».
│ │ │ │
│ │ │ │
All Python code blocks should be formatted using the blacken-docs
│ │ │ │ auto-formatter. This will be run by pre-commit if that is configured.
│ │ │ │ -
Use intersphinx to reference Python’s and Sphinx’
│ │ │ │ +
Use intersphinx to reference Python’s and Sphinx”
│ │ │ │ documentation.
│ │ │ │
Add ..code-block::<lang> to literal blocks so that they get
│ │ │ │ highlighted. Prefer relying on automatic highlighting using ::
│ │ │ │ (two colons). This has the benefit that if the code contains some invalid
│ │ │ │ syntax, it won’t be highlighted. Adding ..code-block::python, for
│ │ │ │ example, will force highlighting despite invalid syntax.
│ │ │ │
To improve readability, use ..admonition::Descriptivetitle rather than
│ │ │ │ @@ -482,21 +483,21 @@
│ │ │ │
Our policy for new features is:
│ │ │ │
│ │ │ │
All documentation of new features should be written in a way that
│ │ │ │ clearly designates the features that are only available in the Django
│ │ │ │ development version. Assume documentation readers are using the latest
│ │ │ │ release, not the development version.
│ │ │ │
│ │ │ │ -
Our preferred way for marking new features is by prefacing the features’
│ │ │ │ -documentation with: “..versionadded::X.Y”, followed by a mandatory
│ │ │ │ +
Our preferred way for marking new features is by prefacing the features”
│ │ │ │ +documentation with: «..versionadded::X.Y», followed by a mandatory
│ │ │ │ blank line and an optional description (indented).
│ │ │ │
General improvements or other changes to the APIs that should be emphasized
│ │ │ │ -should use the “..versionchanged::X.Y” directive (with the same format
│ │ │ │ +should use the «..versionchanged::X.Y» directive (with the same format
│ │ │ │ as the versionadded mentioned above.
│ │ │ │ -
These versionadded and versionchanged blocks should be “self-contained.”
│ │ │ │ +
These versionadded and versionchanged blocks should be «self-contained.»
│ │ │ │ In other words, since we only keep these annotations around for two releases,
│ │ │ │ it’s nice to be able to remove the annotation and its contents without having
│ │ │ │ to reflow, reindent, or edit the surrounding text. For example, instead of
│ │ │ │ putting the entire description of a new or changed feature in a block, do
│ │ │ │ something like this:
Put the changed annotation notes at the bottom of a section, not the top.
│ │ │ │
Also, avoid referring to a specific version of Django outside a
│ │ │ │ versionadded or versionchanged block. Even inside a block, it’s often
│ │ │ │ -redundant to do so as these annotations render as “New in Django A.B:” and
│ │ │ │ -“Changed in Django A.B”, respectively.
│ │ │ │ +redundant to do so as these annotations render as «New in Django A.B:» and
│ │ │ │ +«Changed in Django A.B», respectively.
│ │ │ │
If a function, attribute, etc. is added, it’s also okay to use a
│ │ │ │ versionadded annotation like this:
│ │ │ │
..attribute:: Author.middle_name
│ │ │ │
│ │ │ │ ..versionadded:: A.B
│ │ │ │
│ │ │ │ An author's middle name.
│ │ │ │ @@ -600,15 +601,15 @@
│ │ │ │
│ │ │ │ [("John", "john@example.com"), ("Mary", "mary@example.com")]
│ │ │ │
│ │ │ │ Note that Django will email *all* of these people whenever an error happens.
│ │ │ │ See :doc:`/howto/error-reporting` for more information.
│ │ │ │
│ │ │ │
│ │ │ │ -
This marks up the following header as the “canonical” target for the
│ │ │ │ +
This marks up the following header as the «canonical» target for the
│ │ │ │ setting ADMINS. This means any time I talk about ADMINS,
│ │ │ │ I can reference it using :setting:`ADMINS`.
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ WWrriittiinngg ddooccuummeennttaattiioonn_?¶ ************
│ │ │ │ │ We place high importance on the consistency and readability of documentation.
│ │ │ │ │ After all, Django was created in a journalism environment! So we treat our
│ │ │ │ │ documentation like we treat our code: we aim to improve it as often as
│ │ │ │ │ possible.
│ │ │ │ │ @@ -110,59 +110,59 @@
│ │ │ │ │ to docs/spelling_wordlist (please keep the list in alphabetical order).
│ │ │ │ │ ******** LLiinnkk cchheecckk_?¶ ********
│ │ │ │ │ Links in documentation can become broken or changed such that they are no
│ │ │ │ │ longer the canonical link. Sphinx provides a builder that can check whether the
│ │ │ │ │ links in the documentation are working. From the docs directory, run make
│ │ │ │ │ linkcheck. Output is printed to the terminal, but can also be found in _build/
│ │ │ │ │ linkcheck/output.txt and _build/linkcheck/output.json.
│ │ │ │ │ -Entries that have a status of “working” are fine, those that are “unchecked” or
│ │ │ │ │ -“ignored” have been skipped because they either cannot be checked or have
│ │ │ │ │ +Entries that have a status of «working» are fine, those that are «unchecked» or
│ │ │ │ │ +«ignored» have been skipped because they either cannot be checked or have
│ │ │ │ │ matched ignore rules in the configuration.
│ │ │ │ │ -Entries that have a status of “broken” need to be fixed. Those that have a
│ │ │ │ │ -status of “redirected” may need to be updated to point to the canonical
│ │ │ │ │ +Entries that have a status of «broken» need to be fixed. Those that have a
│ │ │ │ │ +status of «redirected» may need to be updated to point to the canonical
│ │ │ │ │ location, e.g. the scheme has changed http:// → https://. In certain cases, we
│ │ │ │ │ -do not want to update a “redirected” link, e.g. a rewrite to always point to
│ │ │ │ │ +do not want to update a «redirected» link, e.g. a rewrite to always point to
│ │ │ │ │ the latest or stable version of the documentation, e.g. /en/stable/ → /en/3.2/.
│ │ │ │ │ ********** WWrriittiinngg ssttyyllee_?¶ **********
│ │ │ │ │ -When using pronouns in reference to a hypothetical person, such as “a user with
│ │ │ │ │ -a session cookie”, gender-neutral pronouns (they/their/them) should be used.
│ │ │ │ │ +When using pronouns in reference to a hypothetical person, such as «a user with
│ │ │ │ │ +a session cookie», gender-neutral pronouns (they/their/them) should be used.
│ │ │ │ │ Instead of:
│ │ │ │ │ * he or she… use they.
│ │ │ │ │ * him or her… use them.
│ │ │ │ │ * his or her… use their.
│ │ │ │ │ * his or hers… use theirs.
│ │ │ │ │ * himself or herself… use themselves.
│ │ │ │ │ Try to avoid using words that minimize the difficulty involved in a task or
│ │ │ │ │ -operation, such as “easily”, “simply”, “just”, “merely”, “straightforward”, and
│ │ │ │ │ +operation, such as «easily», «simply», «just», «merely», «straightforward», and
│ │ │ │ │ so on. People’s experience may not match your expectations, and they may become
│ │ │ │ │ -frustrated when they do not find a step as “straightforward” or “simple” as it
│ │ │ │ │ +frustrated when they do not find a step as «straightforward» or «simple» as it
│ │ │ │ │ is implied to be.
│ │ │ │ │ ********** CCoommmmoonnllyy uusseedd tteerrmmss_?¶ **********
│ │ │ │ │ Here are some style guidelines on commonly used terms throughout the
│ │ │ │ │ documentation:
│ │ │ │ │ * DDjjaannggoo – when referring to the framework, capitalize Django. It is
│ │ │ │ │ lowercase only in Python code and in the djangoproject.com logo.
│ │ │ │ │ * eemmaaiill – no hyphen.
│ │ │ │ │ - * HHTTTTPP – the expected pronunciation is “Aitch Tee Tee Pee” and therefore
│ │ │ │ │ - should be preceded by “an” and not “a”.
│ │ │ │ │ + * HHTTTTPP – the expected pronunciation is «Aitch Tee Tee Pee» and therefore
│ │ │ │ │ + should be preceded by «an» and not «a».
│ │ │ │ │ * MMyySSQQLL, PPoossttggrreeSSQQLL, SSQQLLiittee
│ │ │ │ │ - * SSQQLL – when referring to SQL, the expected pronunciation should be “Ess
│ │ │ │ │ - Queue Ell” and not “sequel”. Thus in a phrase like “Returns an SQL
│ │ │ │ │ - expression”, “SQL” should be preceded by “an” and not “a”.
│ │ │ │ │ + * SSQQLL – when referring to SQL, the expected pronunciation should be «Ess
│ │ │ │ │ + Queue Ell» and not «sequel». Thus in a phrase like «Returns an SQL
│ │ │ │ │ + expression», «SQL» should be preceded by «an» and not «a».
│ │ │ │ │ * PPyytthhoonn – when referring to the language, capitalize Python.
│ │ │ │ │ - * rreeaalliizzee, ccuussttoommiizzee, iinniittiiaalliizzee, etc. – use the American “ize” suffix, not
│ │ │ │ │ - “ise.”
│ │ │ │ │ - * ssuubbccllaassss – it’s a single word without a hyphen, both as a verb (“subclass
│ │ │ │ │ - that model”) and as a noun (“create a subclass”).
│ │ │ │ │ + * rreeaalliizzee, ccuussttoommiizzee, iinniittiiaalliizzee, etc. – use the American «ize» suffix, not
│ │ │ │ │ + «ise.»
│ │ │ │ │ + * ssuubbccllaassss – it’s a single word without a hyphen, both as a verb («subclass
│ │ │ │ │ + that model») and as a noun («create a subclass»).
│ │ │ │ │ * tthhee wweebb, wweebb ffrraammeewwoorrkk – it’s not capitalized.
│ │ │ │ │ * wweebbssiittee – use one word, without capitalization.
│ │ │ │ │ ********** DDjjaannggoo--ssppeecciiffiicc tteerrmmiinnoollooggyy_?¶ **********
│ │ │ │ │ * mmooddeell – it’s not capitalized.
│ │ │ │ │ * tteemmppllaattee – it’s not capitalized.
│ │ │ │ │ - * UURRLLccoonnff – use three capitalized letters, with no space before “conf.”
│ │ │ │ │ + * UURRLLccoonnff – use three capitalized letters, with no space before «conf.»
│ │ │ │ │ * vviieeww – it’s not capitalized.
│ │ │ │ │ ********** GGuuiiddeelliinneess ffoorr rreeSSttrruuccttuurreeddTTeexxtt ffiilleess_?¶ **********
│ │ │ │ │ These guidelines regulate the format of our reST (reStructuredText)
│ │ │ │ │ documentation:
│ │ │ │ │ * In section titles, capitalize only initial words and proper nouns.
│ │ │ │ │ * Wrap the documentation at 80 characters wide, unless a code example is
│ │ │ │ │ significantly less readable when split over two lines, or for another
│ │ │ │ │ @@ -170,20 +170,20 @@
│ │ │ │ │ * The main thing to keep in mind as you write and edit docs is that the
│ │ │ │ │ more semantic markup you can add the better. So:
│ │ │ │ │ Add ``django.contrib.auth`` to your ``INSTALLED_APPS``...
│ │ │ │ │ Isn’t nearly as helpful as:
│ │ │ │ │ Add :mod:`django.contrib.auth` to your :setting:`INSTALLED_APPS`...
│ │ │ │ │ This is because Sphinx will generate proper links for the latter, which
│ │ │ │ │ greatly helps readers.
│ │ │ │ │ - You can prefix the target with a ~ (that’s a tilde) to get only the “last
│ │ │ │ │ - bit” of that path. So :mod:`~django.contrib.auth` will display a link
│ │ │ │ │ - with the title “auth”.
│ │ │ │ │ + You can prefix the target with a ~ (that’s a tilde) to get only the «last
│ │ │ │ │ + bit» of that path. So :mod:`~django.contrib.auth` will display a link
│ │ │ │ │ + with the title «auth».
│ │ │ │ │ * All Python code blocks should be formatted using the _b_l_a_c_k_e_n_-_d_o_c_s auto-
│ │ │ │ │ formatter. This will be run by pre-commit if that is configured.
│ │ │ │ │ - * Use intersphinx to reference Python’s and Sphinx’ documentation.
│ │ │ │ │ + * Use intersphinx to reference Python’s and Sphinx” documentation.
│ │ │ │ │ * Add .. code-block:: to literal blocks so that they get
│ │ │ │ │ highlighted. Prefer relying on automatic highlighting using :: (two
│ │ │ │ │ colons). This has the benefit that if the code contains some invalid
│ │ │ │ │ syntax, it won’t be highlighted. Adding .. code-block:: python, for
│ │ │ │ │ example, will force highlighting despite invalid syntax.
│ │ │ │ │ * To improve readability, use .. admonition:: Descriptive title rather than
│ │ │ │ │ .. note::. Use these boxes sparingly.
│ │ │ │ │ @@ -268,21 +268,21 @@
│ │ │ │ │ ...\> py manage.py shell
│ │ │ │ │ ********** DDooccuummeennttiinngg nneeww ffeeaattuurreess_?¶ **********
│ │ │ │ │ Our policy for new features is:
│ │ │ │ │ All documentation of new features should be written in a way that
│ │ │ │ │ clearly designates the features that are only available in the Django
│ │ │ │ │ development version. Assume documentation readers are using the
│ │ │ │ │ latest release, not the development version.
│ │ │ │ │ -Our preferred way for marking new features is by prefacing the features’
│ │ │ │ │ -documentation with: “.. versionadded:: X.Y”, followed by a mandatory blank line
│ │ │ │ │ +Our preferred way for marking new features is by prefacing the features”
│ │ │ │ │ +documentation with: «.. versionadded:: X.Y», followed by a mandatory blank line
│ │ │ │ │ and an optional description (indented).
│ │ │ │ │ General improvements or other changes to the APIs that should be emphasized
│ │ │ │ │ -should use the “.. versionchanged:: X.Y” directive (with the same format as the
│ │ │ │ │ +should use the «.. versionchanged:: X.Y» directive (with the same format as the
│ │ │ │ │ versionadded mentioned above.
│ │ │ │ │ -These versionadded and versionchanged blocks should be “self-contained.” In
│ │ │ │ │ +These versionadded and versionchanged blocks should be «self-contained.» In
│ │ │ │ │ other words, since we only keep these annotations around for two releases, it’s
│ │ │ │ │ nice to be able to remove the annotation and its contents without having to
│ │ │ │ │ reflow, reindent, or edit the surrounding text. For example, instead of putting
│ │ │ │ │ the entire description of a new or changed feature in a block, do something
│ │ │ │ │ like this:
│ │ │ │ │ .. class:: Author(first_name, last_name, middle_name=None)
│ │ │ │ │
│ │ │ │ │ @@ -296,15 +296,15 @@
│ │ │ │ │
│ │ │ │ │ .. versionchanged:: A.B
│ │ │ │ │
│ │ │ │ │ The ``middle_name`` argument was added.
│ │ │ │ │ Put the changed annotation notes at the bottom of a section, not the top.
│ │ │ │ │ Also, avoid referring to a specific version of Django outside a versionadded or
│ │ │ │ │ versionchanged block. Even inside a block, it’s often redundant to do so as
│ │ │ │ │ -these annotations render as “New in Django A.B:” and “Changed in Django A.B”,
│ │ │ │ │ +these annotations render as «New in Django A.B:» and «Changed in Django A.B»,
│ │ │ │ │ respectively.
│ │ │ │ │ If a function, attribute, etc. is added, it’s also okay to use a versionadded
│ │ │ │ │ annotation like this:
│ │ │ │ │ .. attribute:: Author.middle_name
│ │ │ │ │
│ │ │ │ │ .. versionadded:: A.B
│ │ │ │ │
│ │ │ │ │ @@ -370,15 +370,15 @@
│ │ │ │ │ of (Full name, email address). Example::
│ │ │ │ │
│ │ │ │ │ [("John", "john@example.com"), ("Mary", "mary@example.com")]
│ │ │ │ │
│ │ │ │ │ Note that Django will email *all* of these people whenever an error
│ │ │ │ │ happens.
│ │ │ │ │ See :doc:`/howto/error-reporting` for more information.
│ │ │ │ │ - This marks up the following header as the “canonical” target for the
│ │ │ │ │ + This marks up the following header as the «canonical» target for the
│ │ │ │ │ setting ADMINS. This means any time I talk about ADMINS, I can reference
│ │ │ │ │ it using :setting:`ADMINS`.
│ │ │ │ │ That’s basically how everything fits together.
│ │ │ │ │ ********** TTrraannssllaattiinngg ddooccuummeennttaattiioonn_?¶ **********
│ │ │ │ │ See _L_o_c_a_l_i_z_i_n_g_ _t_h_e_ _D_j_a_n_g_o_ _d_o_c_u_m_e_n_t_a_t_i_o_n if you’d like to help translate the
│ │ │ │ │ documentation into another language.
│ │ │ │ │ ********** ddjjaannggoo--aaddmmiinn mmaann ppaaggee_?¶ **********
│ │ │ │ │ @@ -406,16 +406,16 @@
│ │ │ │ │ o _G_u_i_d_e_l_i_n_e_s_ _f_o_r_ _r_e_S_t_r_u_c_t_u_r_e_d_T_e_x_t_ _f_i_l_e_s
│ │ │ │ │ o _D_j_a_n_g_o_-_s_p_e_c_i_f_i_c_ _m_a_r_k_u_p
│ │ │ │ │ o _D_o_c_u_m_e_n_t_i_n_g_ _n_e_w_ _f_e_a_t_u_r_e_s
│ │ │ │ │ o _M_i_n_i_m_i_z_i_n_g_ _i_m_a_g_e_s
│ │ │ │ │ o _A_n_ _e_x_a_m_p_l_e
│ │ │ │ │ o _T_r_a_n_s_l_a_t_i_n_g_ _d_o_c_u_m_e_n_t_a_t_i_o_n
│ │ │ │ │ o _d_j_a_n_g_o_-_a_d_m_i_n_ _m_a_n_ _p_a_g_e
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _C_o_m_m_i_t_t_i_n_g_ _c_o_d_e
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _L_o_c_a_l_i_z_i_n_g_ _D_j_a_n_g_o
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/internals/deprecation.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Django Deprecation Timeline — Django 5.1b1 documentation
│ │ │ │ + Django Deprecation Timeline — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,15 +54,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
The module django.test.simple and the class
│ │ │ │ django.test.simple.DjangoTestSuiteRunner will be removed. Instead use
│ │ │ │ django.test.runner.DiscoverRunner.
│ │ │ │
The module django.test._doctest will be removed. Instead use the doctest
│ │ │ │ module from the Python standard library.
│ │ │ │
The CACHE_MIDDLEWARE_ANONYMOUS_ONLY setting will be removed.
│ │ │ │ -
Usage of the hard-coded Hold down “Control”, or “Command” on a Mac, to select
│ │ │ │ +
Usage of the hard-coded Hold down «Control», or «Command» on a Mac, to select
│ │ │ │ more than one. string to override or append to user-provided help_text in
│ │ │ │ forms for ManyToMany model fields will not be performed by Django anymore
│ │ │ │ either at the model or forms layer.
│ │ │ │
The Model._meta.get_(add|change|delete)_permission methods will
│ │ │ │ be removed.
│ │ │ │
The session key django_language will no longer be read for backwards
│ │ │ │ compatibility.
If you’d like to try out the in-development code for the next release of
│ │ │ │ Django, or if you’d like to contribute to Django by fixing bugs or developing
│ │ │ │ new features, you’ll want to get the code from the main branch.
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
Prior to March 2021, the main branch was called master.
│ │ │ │
│ │ │ │
Note that this will get all of Django: in addition to the top-level
│ │ │ │ django module containing Python code, you’ll also get a copy of Django’s
│ │ │ │ documentation, test suite, packaging scripts and other miscellaneous bits.
│ │ │ │ Django’s code will be present in your clone as a directory named
│ │ │ │ django.
│ │ │ │ @@ -126,15 +127,15 @@
│ │ │ │ Linux, or md5 and shasum on macOS)
│ │ │ │
python
│ │ │ │
ssh
│ │ │ │
│ │ │ │
│ │ │ │
A GPG key pair. Ensure that the private part of this key is securely stored.
│ │ │ │ The public part needs to be uploaded to your GitHub account, and also to the
│ │ │ │ -Jenkins server running the “confirm release” job.
│ │ │ │ +Jenkins server running the «confirm release» job.
│ │ │ │
│ │ │ │
More than one GPG key
│ │ │ │
If the key you want to use is not your default signing key, you’ll need to
│ │ │ │ add -uyou@example.com to every GPG signing command shown below, where
│ │ │ │ you@example.com is the email address associated with the key you want
│ │ │ │ to use.
│ │ │ │ @@ -272,15 +273,15 @@
│ │ │ │ POT-Creation-Date. You can use a command similar to this to bulk update
│ │ │ │ all the .po files (compare the diff against the relevant stable branch):
│ │ │ │
All the new .po files should be manually and carefully inspected to
│ │ │ │ avoid committing a change in a file without any new translations. Also,
│ │ │ │ -there shouldn’t be any changes in the “plural forms”: if there are any
│ │ │ │ +there shouldn’t be any changes in the «plural forms»: if there are any
│ │ │ │ (usually Spanish and French report changes for this) those will need
│ │ │ │ reverting.
│ │ │ │
Lastly, commit the changed/added files (both .po and .mo) and create
│ │ │ │ a new PR targeting the stable branch of the corresponding release (example
│ │ │ │ PR updating translations for 4.2).
At the same time, update the django_next_version variable in
│ │ │ │ docs/conf.py on the stable release branch to point to the new
│ │ │ │ development version. For example, when creating stable/4.2.x, set
│ │ │ │ django_next_version to '5.0' on the new branch.
│ │ │ │
│ │ │ │ -
If this is the “dot zero” release of a new series, create a new branch from
│ │ │ │ +
If this is the «dot zero» release of a new series, create a new branch from
│ │ │ │ the current stable branch in the django-docs-translations repository. For
│ │ │ │ example, when releasing Django 4.2:
│ │ │ │ @@ -365,15 +366,15 @@
│ │ │ │ that the commit is a security fix and that an announcement will follow
│ │ │ │ (example security commit).
│ │ │ │
│ │ │ │
Create a «checksums» file, Django-<<VERSION>>.checksum.txt containing
│ │ │ │ the hashes and release information. Start with this template and insert the
│ │ │ │ correct version, date, GPG key ID (from
│ │ │ │ gpg--list-keys--keyid-formatLONG), release manager’s GitHub username,
│ │ │ │ release URL, and checksums:
│ │ │ │
This file contains MD5, SHA1, and SHA256 checksums for the source-code
│ │ │ │ tarball and wheel files of Django <<VERSION>>, released <<DATE>>.
│ │ │ │
│ │ │ │ @@ -522,15 +523,15 @@
│ │ │ │ file):
│ │ │ │
$twineuploaddist/*
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Go to the Add release page in the admin, enter the new release number
│ │ │ │ exactly as it appears in the name of the tarball
│ │ │ │ -(Django-<version>.tar.gz). So for example enter “4.1.1” or “4.2rc1”,
│ │ │ │ +(Django-<version>.tar.gz). So for example enter «4.1.1» or «4.2rc1»,
│ │ │ │ etc. If the release is part of an LTS branch, mark it so.
│ │ │ │
If this is the alpha release of a new series, also create a Release object
│ │ │ │ for the final release, ensuring that the Release date field is blank,
│ │ │ │ thus marking it as unreleased. For example, when creating the Release
│ │ │ │ object for 4.2a1, also create 4.2 with the Release date field blank.
│ │ │ │
│ │ │ │
Make the blog post announcing the release live.
│ │ │ │ @@ -552,15 +553,15 @@
│ │ │ │
│ │ │ │
│ │ │ │
Post the release announcement to the django-announce, django-developers,
│ │ │ │ django-users mailing lists, and the Django Forum. This should include a
│ │ │ │ link to the announcement blog post.
│ │ │ │
If this is a security release, send a separate email to
│ │ │ │ oss-security@lists.openwall.com. Provide a descriptive subject, for example,
│ │ │ │ -“Django” plus the issue title from the release notes (including CVE ID). The
│ │ │ │ +«Django» plus the issue title from the release notes (including CVE ID). The
│ │ │ │ message body should include the vulnerability details, for example, the
│ │ │ │ announcement blog post text. Include a link to the announcement blog post.
│ │ │ │
Add a link to the blog post in the topic of the #django IRC channel:
│ │ │ │ /msgchanservTOPIC#djangonewtopicgoeshere.
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -571,15 +572,15 @@
│ │ │ │ incrementing to whatever the next expected release will be. For
│ │ │ │ example, after releasing 4.1.1, update VERSION to
│ │ │ │ VERSION=(4,1,2,'alpha',0).
│ │ │ │
Add the release in Trac’s versions list if necessary (and make it the
│ │ │ │ default by changing the default_version setting in the
│ │ │ │ code.djangoproject.com’s trac.ini, if it’s a final release). The new X.Y
│ │ │ │ version should be added after the alpha release and the default version
│ │ │ │ -should be updated after “dot zero” release.
│ │ │ │ +should be updated after «dot zero» release.
│ │ │ │
│ │ │ │
If this was a final release:
│ │ │ │
│ │ │ │
Update the current stable branch and remove the pre-release branch in the
│ │ │ │ Django release process on Trac.
Increase the default PBKDF2 iterations in
│ │ │ │ django.contrib.auth.hashers.PBKDF2PasswordHasher by about 20%
│ │ │ │ (pick a round number). Run the tests, and update the 3 failing
│ │ │ │ hasher tests with the new values. Make sure this gets noted in the
│ │ │ │ release notes (see the 4.1 release notes for an example).
│ │ │ │
Remove features that have reached the end of their deprecation cycle. Each
│ │ │ │ removal should be done in a separate commit for clarity. In the commit
│ │ │ │ -message, add a “refs #XXXX” to the original ticket where the deprecation
│ │ │ │ +message, add a «refs #XXXX» to the original ticket where the deprecation
│ │ │ │ began if possible.
│ │ │ │
Remove ..versionadded::, ..versionadded::, and ..deprecated::
│ │ │ │ annotations in the documentation from two releases ago. For example, in
│ │ │ │ Django 4.2, notes for 4.0 will be removed.
│ │ │ │
Add the new branch to Read the Docs. Since the automatically
│ │ │ │ -generated version names (“stable-A.B.x”) differ from the version names
│ │ │ │ -used in Read the Docs (“A.B.x”), create a ticket requesting
│ │ │ │ +generated version names («stable-A.B.x») differ from the version names
│ │ │ │ +used in Read the Docs («A.B.x»), create a ticket requesting
│ │ │ │ the new version.
For a final release, the status is always “final” and the series
│ │ │ │ -number is always 0. A series number of 0 with an “alpha” status will
│ │ │ │ -be reported as “pre-alpha”.
│ │ │ │ +
For a final release, the status is always «final» and the series
│ │ │ │ +number is always 0. A series number of 0 with an «alpha» status will
│ │ │ │ +be reported as «pre-alpha».
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p
│ │ │ │ │ ************ HHooww iiss DDjjaannggoo FFoorrmmeedd??_?¶ ************
│ │ │ │ │ This document explains how to release Django.
│ │ │ │ │ PPlleeaassee,, kkeeeepp tthheessee iinnssttrruuccttiioonnss uupp--ttoo--ddaattee iiff yyoouu mmaakkee cchhaannggeess!! The point here
│ │ │ │ │ is to be descriptive, not prescriptive, so feel free to streamline or otherwise
│ │ │ │ │ make changes, but uuppddaattee tthhiiss ddooccuummeenntt aaccccoorrddiinnggllyy!!
│ │ │ │ │ @@ -41,15 +41,15 @@
│ │ │ │ │ o man
│ │ │ │ │ o hashing tools (typically md5sum, sha1sum, and sha256sum on Linux,
│ │ │ │ │ or md5 and shasum on macOS)
│ │ │ │ │ o python
│ │ │ │ │ o ssh
│ │ │ │ │ * A GPG key pair. Ensure that the private part of this key is securely
│ │ │ │ │ stored. The public part needs to be uploaded to your GitHub account, and
│ │ │ │ │ - also to the Jenkins server running the “confirm release” job.
│ │ │ │ │ + also to the Jenkins server running the «confirm release» job.
│ │ │ │ │ More than one GPG key
│ │ │ │ │ If the key you want to use is not your default signing key, you’ll need
│ │ │ │ │ to add -u you@example.com to every GPG signing command shown below, where
│ │ │ │ │ you@example.com is the email address associated with the key you want to
│ │ │ │ │ use.
│ │ │ │ │ * A clean Python virtual environment per Django version being released,
│ │ │ │ │ with these required Python packages installed:
│ │ │ │ │ @@ -77,15 +77,15 @@
│ │ │ │ │ API Token in the _u_s_e_r_ _s_e_t_t_i_n_g_ _s_e_c_t_i_o_n and set up your $HOME/.transifexrc
│ │ │ │ │ file like this:
│ │ │ │ │ ~/.transifexrc_¶
│ │ │ │ │ [https://www.transifex.com]
│ │ │ │ │ rest_hostname = https://rest.api.transifex.com
│ │ │ │ │ token = # API token
│ │ │ │ │ * Access to the djangoproject.com server to upload files (using scp).
│ │ │ │ │ - * Access to the Django admin on djangoproject.com as a “Site maintainer”.
│ │ │ │ │ + * Access to the Django admin on djangoproject.com as a «Site maintainer».
│ │ │ │ │ * Access to create a post in the _D_j_a_n_g_o_ _F_o_r_u_m_ _-_ _A_n_n_o_u_n_c_e_m_e_n_t_s_ _c_a_t_e_g_o_r_y and
│ │ │ │ │ to send emails to the following mailing lists:
│ │ │ │ │ o _d_j_a_n_g_o_-_u_s_e_r_s
│ │ │ │ │ o _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s
│ │ │ │ │ o _d_j_a_n_g_o_-_a_n_n_o_u_n_c_e
│ │ │ │ │ * Access to the django-security repo in GitHub. Among other things, this
│ │ │ │ │ provides access to the pre-notification distribution list (needed for
│ │ │ │ │ @@ -147,15 +147,15 @@
│ │ │ │ │ all, the PO-Revision-Date values must be manually bumped to be later than
│ │ │ │ │ POT-Creation-Date. You can use a command similar to this to bulk update
│ │ │ │ │ all the .po files (compare the diff against the relevant stable branch):
│ │ │ │ │ $ git diff --name-only stable/5.0.x | grep "\.po" | xargs sed -ri "s/PO-
│ │ │ │ │ Revision-Date: [0-9\-]+ /PO-Revision-Date: $(date -I) /g"
│ │ │ │ │ All the new .po files should be manually and carefully inspected to avoid
│ │ │ │ │ committing a change in a file without any new translations. Also, there
│ │ │ │ │ - shouldn’t be any changes in the “plural forms”: if there are any (usually
│ │ │ │ │ + shouldn’t be any changes in the «plural forms»: if there are any (usually
│ │ │ │ │ Spanish and French report changes for this) those will need reverting.
│ │ │ │ │ Lastly, commit the changed/added files (both .po and .mo) and create a
│ │ │ │ │ new PR targeting the stable branch of the corresponding release (example
│ │ │ │ │ _P_R_ _u_p_d_a_t_i_n_g_ _t_r_a_n_s_l_a_t_i_o_n_s_ _f_o_r_ _4_._2).
│ │ │ │ │ 7. _U_p_d_a_t_e_ _t_h_e_ _d_j_a_n_g_o_-_a_d_m_i_n_ _m_a_n_u_a_l_ _p_a_g_e:
│ │ │ │ │ $ cd docs
│ │ │ │ │ $ make man
│ │ │ │ │ @@ -166,15 +166,15 @@
│ │ │ │ │ from main. For example, when releasing Django 4.2:
│ │ │ │ │ $ git checkout -b stable/4.2.x origin/main
│ │ │ │ │ $ git push origin -u stable/4.2.x:stable/4.2.x
│ │ │ │ │ At the same time, update the django_next_version variable in docs/conf.py
│ │ │ │ │ on the stable release branch to point to the new development version. For
│ │ │ │ │ example, when creating stable/4.2.x, set django_next_version to '5.0' on
│ │ │ │ │ the new branch.
│ │ │ │ │ - 9. If this is the “dot zero” release of a new series, create a new branch
│ │ │ │ │ + 9. If this is the «dot zero» release of a new series, create a new branch
│ │ │ │ │ from the current stable branch in the _d_j_a_n_g_o_-_d_o_c_s_-_t_r_a_n_s_l_a_t_i_o_n_s
│ │ │ │ │ repository. For example, when releasing Django 4.2:
│ │ │ │ │ $ git checkout -b stable/4.2.x origin/stable/4.1.x
│ │ │ │ │ $ git push origin stable/4.2.x:stable/4.2.x
│ │ │ │ │ 10. Write the announcement blog post for the release. You can enter it into
│ │ │ │ │ the admin at any time and mark it as inactive. Here are a few examples:
│ │ │ │ │ _e_x_a_m_p_l_e_ _s_e_c_u_r_i_t_y_ _r_e_l_e_a_s_e_ _a_n_n_o_u_n_c_e_m_e_n_t, _e_x_a_m_p_l_e_ _r_e_g_u_l_a_r_ _r_e_l_e_a_s_e
│ │ │ │ │ @@ -214,16 +214,16 @@
│ │ │ │ │ checkout security/4.1.x; git rebase stable/4.1.x) and then switch back
│ │ │ │ │ and do the merge. Make sure the commit message for each security fix
│ │ │ │ │ explains that the commit is a security fix and that an announcement will
│ │ │ │ │ follow (_e_x_a_m_p_l_e_ _s_e_c_u_r_i_t_y_ _c_o_m_m_i_t).
│ │ │ │ │ 5. Update the version number in django/__init__.py for the release. Please
│ │ │ │ │ see _n_o_t_e_s_ _o_n_ _s_e_t_t_i_n_g_ _t_h_e_ _V_E_R_S_I_O_N_ _t_u_p_l_e below for details on VERSION
│ │ │ │ │ (_e_x_a_m_p_l_e_ _c_o_m_m_i_t).
│ │ │ │ │ - 1. If this is a pre-release package also update the “Development
│ │ │ │ │ - Status” trove classifier in pyproject.toml to reflect this. An rc
│ │ │ │ │ + 1. If this is a pre-release package also update the «Development
│ │ │ │ │ + Status» trove classifier in pyproject.toml to reflect this. An rc
│ │ │ │ │ pre-release should not change the trove classifier (_e_x_a_m_p_l_e_ _c_o_m_m_i_t
│ │ │ │ │ _f_o_r_ _a_l_p_h_a_ _r_e_l_e_a_s_e, _e_x_a_m_p_l_e_ _c_o_m_m_i_t_ _f_o_r_ _b_e_t_a_ _r_e_l_e_a_s_e).
│ │ │ │ │ 2. Otherwise, make sure the classifier is set to Development Status ::
│ │ │ │ │ 5 - Production/Stable.
│ │ │ │ │ 6. Tag the release using git tag. For example:
│ │ │ │ │ $ git tag --sign --message="Tag 4.1.1" 4.1.1
│ │ │ │ │ You can check your work running git tag --verify .
│ │ │ │ │ @@ -234,15 +234,15 @@
│ │ │ │ │ 9. Run python -m build to generate the release packages. This will create
│ │ │ │ │ the release packages in a dist/ directory.
│ │ │ │ │ 10. Generate the hashes of the release packages:
│ │ │ │ │ $ cd dist
│ │ │ │ │ $ md5sum *
│ │ │ │ │ $ sha1sum *
│ │ │ │ │ $ sha256sum *
│ │ │ │ │ - 11. Create a “checksums” file, Django-<>.checksum.txt containing the
│ │ │ │ │ + 11. Create a «checksums» file, Django-<>.checksum.txt containing the
│ │ │ │ │ hashes and release information. Start with this template and insert the
│ │ │ │ │ correct version, date, GPG key ID (from gpg --list-keys --keyid-format
│ │ │ │ │ LONG), release manager’s GitHub username, release URL, and checksums:
│ │ │ │ │ This file contains MD5, SHA1, and SHA256 checksums for the source-code
│ │ │ │ │ tarball and wheel files of Django <>, released <>.
│ │ │ │ │
│ │ │ │ │ To use this file, you will need a working install of PGP or other
│ │ │ │ │ @@ -344,15 +344,15 @@
│ │ │ │ │ (e.g. use 4.2rc1 for _h_t_t_p_s_:_/_/_m_e_d_i_a_._d_j_a_n_g_o_p_r_o_j_e_c_t_._c_o_m_/_p_g_p_/_D_j_a_n_g_o_-
│ │ │ │ │ _4_._2_r_c_1_._c_h_e_c_k_s_u_m_._t_x_t).
│ │ │ │ │ 5. Upload the release packages to PyPI (for pre-releases, only upload the
│ │ │ │ │ wheel file):
│ │ │ │ │ $ twine upload dist/*
│ │ │ │ │ 6. Go to the _A_d_d_ _r_e_l_e_a_s_e_ _p_a_g_e_ _i_n_ _t_h_e_ _a_d_m_i_n, enter the new release number
│ │ │ │ │ exactly as it appears in the name of the tarball (Django-
│ │ │ │ │ - .tar.gz). So for example enter “4.1.1” or “4.2rc1”, etc. If the
│ │ │ │ │ + .tar.gz). So for example enter «4.1.1» or «4.2rc1», etc. If the
│ │ │ │ │ release is part of an LTS branch, mark it so.
│ │ │ │ │ If this is the alpha release of a new series, also create a Release
│ │ │ │ │ object for the ffiinnaall release, ensuring that the RReelleeaassee ddaattee field is
│ │ │ │ │ blank, thus marking it as uunnrreelleeaasseedd. For example, when creating the
│ │ │ │ │ Release object for 4.2a1, also create 4.2 with the Release date field
│ │ │ │ │ blank.
│ │ │ │ │ 7. Make the blog post announcing the release live.
│ │ │ │ │ @@ -371,30 +371,30 @@
│ │ │ │ │ $ git pull
│ │ │ │ │ $ python manage_translations.py robots_txt
│ │ │ │ │ 9. Post the release announcement to the _d_j_a_n_g_o_-_a_n_n_o_u_n_c_e, _d_j_a_n_g_o_-_d_e_v_e_l_o_p_e_r_s,
│ │ │ │ │ _d_j_a_n_g_o_-_u_s_e_r_s mailing lists, and the Django Forum. This should include a
│ │ │ │ │ link to the announcement blog post.
│ │ │ │ │ 10. If this is a security release, send a separate email to _o_s_s_-
│ │ │ │ │ _s_e_c_u_r_i_t_y_@_l_i_s_t_s_._o_p_e_n_w_a_l_l_._c_o_m. Provide a descriptive subject, for example,
│ │ │ │ │ - “Django” plus the issue title from the release notes (including CVE ID).
│ │ │ │ │ + «Django» plus the issue title from the release notes (including CVE ID).
│ │ │ │ │ The message body should include the vulnerability details, for example,
│ │ │ │ │ the announcement blog post text. Include a link to the announcement blog
│ │ │ │ │ post.
│ │ │ │ │ 11. Add a link to the blog post in the topic of the #django IRC channel: /msg
│ │ │ │ │ chanserv TOPIC #django new topic goes here.
│ │ │ │ │ ********** PPoosstt--rreelleeaassee_?¶ **********
│ │ │ │ │ You’re almost done! All that’s left to do now is:
│ │ │ │ │ 1. Update the VERSION tuple in django/__init__.py again, incrementing to
│ │ │ │ │ whatever the next expected release will be. For example, after releasing
│ │ │ │ │ 4.1.1, update VERSION to VERSION = (4, 1, 2, 'alpha', 0).
│ │ │ │ │ 2. Add the release in _T_r_a_c_’_s_ _v_e_r_s_i_o_n_s_ _l_i_s_t if necessary (and make it the
│ │ │ │ │ default by changing the default_version setting in the
│ │ │ │ │ code.djangoproject.com’s _t_r_a_c_._i_n_i, if it’s a final release). The new X.Y
│ │ │ │ │ version should be added after the alpha release and the default version
│ │ │ │ │ - should be updated after “dot zero” release.
│ │ │ │ │ + should be updated after «dot zero» release.
│ │ │ │ │ 3. If this was a final release:
│ │ │ │ │ 1. Update the current stable branch and remove the pre-release branch
│ │ │ │ │ in the _D_j_a_n_g_o_ _r_e_l_e_a_s_e_ _p_r_o_c_e_s_s on Trac.
│ │ │ │ │ 2. Update djangoproject.com’s download page (_e_x_a_m_p_l_e_ _P_R).
│ │ │ │ │ 4. If this was a security release, update _A_r_c_h_i_v_e_ _o_f_ _s_e_c_u_r_i_t_y_ _i_s_s_u_e_s with
│ │ │ │ │ details of the issues addressed.
│ │ │ │ │ ********** NNeeww ssttaabbllee bbrraanncchh ttaasskkss_?¶ **********
│ │ │ │ │ @@ -413,55 +413,55 @@
│ │ │ │ │ 3. Increase the default PBKDF2 iterations in
│ │ │ │ │ django.contrib.auth.hashers.PBKDF2PasswordHasher by about 20% (pick a
│ │ │ │ │ round number). Run the tests, and update the 3 failing hasher tests with
│ │ │ │ │ the new values. Make sure this gets noted in the release notes (see the
│ │ │ │ │ 4.1 release notes for an example).
│ │ │ │ │ 4. Remove features that have reached the end of their deprecation cycle.
│ │ │ │ │ Each removal should be done in a separate commit for clarity. In the
│ │ │ │ │ - commit message, add a “refs #XXXX” to the original ticket where the
│ │ │ │ │ + commit message, add a «refs #XXXX» to the original ticket where the
│ │ │ │ │ deprecation began if possible.
│ │ │ │ │ 5. Remove .. versionadded::, .. versionadded::, and .. deprecated::
│ │ │ │ │ annotations in the documentation from two releases ago. For example, in
│ │ │ │ │ Django 4.2, notes for 4.0 will be removed.
│ │ │ │ │ 6. Add the new branch to _R_e_a_d_ _t_h_e_ _D_o_c_s. Since the automatically generated
│ │ │ │ │ - version names (“stable-A.B.x”) differ from the version names used in Read
│ │ │ │ │ - the Docs (“A.B.x”), _c_r_e_a_t_e_ _a_ _t_i_c_k_e_t requesting the new version.
│ │ │ │ │ + version names («stable-A.B.x») differ from the version names used in Read
│ │ │ │ │ + the Docs («A.B.x»), _c_r_e_a_t_e_ _a_ _t_i_c_k_e_t requesting the new version.
│ │ │ │ │ 7. _R_e_q_u_e_s_t_ _t_h_e_ _n_e_w_ _c_l_a_s_s_i_f_i_e_r_ _o_n_ _P_y_P_I. For example Framework :: Django ::
│ │ │ │ │ 3.1.
│ │ │ │ │ 8. Update the current branch under active development and add pre-release
│ │ │ │ │ branch in the _D_j_a_n_g_o_ _r_e_l_e_a_s_e_ _p_r_o_c_e_s_s on Trac.
│ │ │ │ │ ********** NNootteess oonn sseettttiinngg tthhee VVEERRSSIIOONN ttuuppllee_?¶ **********
│ │ │ │ │ Django’s version reporting is controlled by the VERSION tuple in django/
│ │ │ │ │ __init__.py. This is a five-element tuple, whose elements are:
│ │ │ │ │ 1. Major version.
│ │ │ │ │ 2. Minor version.
│ │ │ │ │ 3. Micro version.
│ │ │ │ │ - 4. Status – can be one of “alpha”, “beta”, “rc” or “final”.
│ │ │ │ │ + 4. Status – can be one of «alpha», «beta», «rc» or «final».
│ │ │ │ │ 5. Series number, for alpha/beta/RC packages which run in sequence
│ │ │ │ │ - (allowing, for example, “beta 1”, “beta 2”, etc.).
│ │ │ │ │ -For a final release, the status is always “final” and the series number is
│ │ │ │ │ -always 0. A series number of 0 with an “alpha” status will be reported as “pre-
│ │ │ │ │ -alpha”.
│ │ │ │ │ + (allowing, for example, «beta 1», «beta 2», etc.).
│ │ │ │ │ +For a final release, the status is always «final» and the series number is
│ │ │ │ │ +always 0. A series number of 0 with an «alpha» status will be reported as «pre-
│ │ │ │ │ +alpha».
│ │ │ │ │ Some examples:
│ │ │ │ │ - * (4, 1, 1, "final", 0) → “4.1.1”
│ │ │ │ │ - * (4, 2, 0, "alpha", 0) → “4.2 pre-alpha”
│ │ │ │ │ - * (4, 2, 0, "beta", 1) → “4.2 beta 1”
│ │ │ │ │ + * (4, 1, 1, "final", 0) → «4.1.1»
│ │ │ │ │ + * (4, 2, 0, "alpha", 0) → «4.2 pre-alpha»
│ │ │ │ │ + * (4, 2, 0, "beta", 1) → «4.2 beta 1»
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ * _H_o_w_ _i_s_ _D_j_a_n_g_o_ _F_o_r_m_e_d_?
│ │ │ │ │ o _O_v_e_r_v_i_e_w
│ │ │ │ │ o _P_r_e_r_e_q_u_i_s_i_t_e_s
│ │ │ │ │ o _P_r_e_-_r_e_l_e_a_s_e_ _t_a_s_k_s
│ │ │ │ │ # _1_0_ _(_o_r_ _m_o_r_e_)_ _d_a_y_s_ _b_e_f_o_r_e_ _a_ _s_e_c_u_r_i_t_y_ _r_e_l_e_a_s_e
│ │ │ │ │ # _A_ _w_e_e_k_ _b_e_f_o_r_e_ _a_ _s_e_c_u_r_i_t_y_ _r_e_l_e_a_s_e
│ │ │ │ │ # _A_ _f_e_w_ _d_a_y_s_ _b_e_f_o_r_e_ _a_n_y_ _r_e_l_e_a_s_e
│ │ │ │ │ o _A_c_t_u_a_l_l_y_ _r_o_l_l_i_n_g_ _t_h_e_ _r_e_l_e_a_s_e
│ │ │ │ │ o _M_a_k_i_n_g_ _t_h_e_ _r_e_l_e_a_s_e_(_s_)_ _a_v_a_i_l_a_b_l_e_ _t_o_ _t_h_e_ _p_u_b_l_i_c
│ │ │ │ │ o _P_o_s_t_-_r_e_l_e_a_s_e
│ │ │ │ │ o _N_e_w_ _s_t_a_b_l_e_ _b_r_a_n_c_h_ _t_a_s_k_s
│ │ │ │ │ o _N_o_t_e_s_ _o_n_ _s_e_t_t_i_n_g_ _t_h_e_ _V_E_R_S_I_O_N_ _t_u_p_l_e
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _T_h_e_ _D_j_a_n_g_o_ _s_o_u_r_c_e_ _c_o_d_e_ _r_e_p_o_s_i_t_o_r_y
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p
│ │ │ ├── ./usr/share/doc/python-django-doc/html/internals/index.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Django internals — Django 5.1b1 documentation
│ │ │ │ + Django internals — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,25 +54,25 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Please report security issues only to
│ │ │ │ security@djangoproject.com. This is a private list only open to
│ │ │ │ long-time, highly trusted Django developers, and its archives are
│ │ │ │ not public. For further details, please see our security
│ │ │ │ policies.
The Using Django category of the official Forum is now the preferred
│ │ │ │ venue for asking usage questions.
│ │ │ │
│ │ │ │
This is the right place if you are looking to ask any question regarding the
│ │ │ │ installation, usage, or debugging of Django.
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
If it’s the first time you send an email to this list, your email must be
│ │ │ │ accepted first so don’t worry if your message does not appear instantly.
Becoming disqualified due to actions taken by the Code of Conduct committee
│ │ │ │ of the Django Software Foundation.
│ │ │ │
Determining that they did not possess the qualifications of a member of the
│ │ │ │ steering council. This determination must be made jointly by the other members
│ │ │ │ of the steering council, and the DSF Board. A valid determination of
│ │ │ │ ineligibility requires that all other members of the steering council and all
│ │ │ │ members of the DSF Board vote who can vote on the issue (the affected person,
│ │ │ │ -if a DSF Board member, must not vote) vote “yes” on a motion that the person
│ │ │ │ +if a DSF Board member, must not vote) vote «yes» on a motion that the person
│ │ │ │ in question is ineligible.
Patch releases (A.B.C, A.B.C+1, etc.) will be issued as needed, to fix
│ │ │ │ bugs and/or security issues.
│ │ │ │
These releases will be 100% compatible with the associated feature release,
│ │ │ │ unless this is impossible for security reasons or to prevent data loss.
│ │ │ │ -So the answer to “should I upgrade to the latest patch release?” will always
│ │ │ │ -be “yes.”
│ │ │ │ +So the answer to «should I upgrade to the latest patch release?» will always
│ │ │ │ +be «yes.»
│ │ │ │
Certain feature releases will be designated as long-term support (LTS)
│ │ │ │ releases. These releases will get security and data loss fixes applied for
│ │ │ │ a guaranteed period of time, typically three years.
│ │ │ │
See the download page for the releases that have been designated for
│ │ │ │ long-term support.
Starting with Django 2.0, version numbers will use a loose form of semantic
│ │ │ │ versioning such that each version following an LTS will
│ │ │ │ -bump to the next “dot zero” version. For example: 2.0, 2.1, 2.2 (LTS), 3.0,
│ │ │ │ +bump to the next «dot zero» version. For example: 2.0, 2.1, 2.2 (LTS), 3.0,
│ │ │ │ 3.1, 3.2 (LTS), etc.
│ │ │ │
SemVer makes it easier to see at a glance how compatible releases are with each
│ │ │ │ other. It also helps to anticipate when compatibility shims will be removed.
│ │ │ │ It’s not a pure form of SemVer as each feature release will continue to have a
│ │ │ │ few documented backwards incompatibilities where a deprecation path isn’t
│ │ │ │ possible or not worth the cost. Also, deprecations started in an LTS release
│ │ │ │ (X.2) will be dropped in a non-dot-zero release (Y.1) to accommodate our policy
│ │ │ │ @@ -231,15 +232,15 @@
│ │ │ │ features to include in the next version. This should include a good deal of
│ │ │ │ preliminary work on those features – working code trumps grand design.
The second part of the release schedule is the “heads-down” working period.
│ │ │ │ +
The second part of the release schedule is the «heads-down» working period.
│ │ │ │ Using the roadmap produced at the end of phase one, we’ll all work very hard to
│ │ │ │ get everything on it done.
│ │ │ │
At the end of phase two, any unfinished features will be postponed until the
│ │ │ │ next release.
│ │ │ │
Phase two will culminate with an alpha release. At this point, the
│ │ │ │ stable/A.B.x branch will be forked from main.
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ DDjjaannggoo?’ss rreelleeaassee pprroocceessss_?¶ ************
│ │ │ │ │ ********** OOffffiicciiaall rreelleeaasseess_?¶ **********
│ │ │ │ │ Since version 1.0, Django’s release numbering works as follows:
│ │ │ │ │ * Versions are numbered in the form A.B or A.B.C.
│ │ │ │ │ * A.B is the ffeeaattuurree rreelleeaassee version number. Each version will be mostly
│ │ │ │ │ @@ -28,26 +28,26 @@
│ │ │ │ │ months – see _r_e_l_e_a_s_e_ _p_r_o_c_e_s_s for details. These releases will contain new
│ │ │ │ │ features, improvements to existing features, and such.
│ │ │ │ │ Patch release_¶
│ │ │ │ │ Patch releases (A.B.C, A.B.C+1, etc.) will be issued as needed, to fix
│ │ │ │ │ bugs and/or security issues.
│ │ │ │ │ These releases will be 100% compatible with the associated feature
│ │ │ │ │ release, unless this is impossible for security reasons or to prevent
│ │ │ │ │ - data loss. So the answer to “should I upgrade to the latest patch
│ │ │ │ │ - release?” will always be “yes.”
│ │ │ │ │ + data loss. So the answer to «should I upgrade to the latest patch
│ │ │ │ │ + release?» will always be «yes.»
│ │ │ │ │ Long-term support release_¶
│ │ │ │ │ Certain feature releases will be designated as long-term support (LTS)
│ │ │ │ │ releases. These releases will get security and data loss fixes applied
│ │ │ │ │ for a guaranteed period of time, typically three years.
│ │ │ │ │ See _t_h_e_ _d_o_w_n_l_o_a_d_ _p_a_g_e for the releases that have been designated for
│ │ │ │ │ long-term support.
│ │ │ │ │ ********** RReelleeaassee ccaaddeennccee_?¶ **********
│ │ │ │ │ Starting with Django 2.0, version numbers will use a loose form of _s_e_m_a_n_t_i_c
│ │ │ │ │ -_v_e_r_s_i_o_n_i_n_g such that each version following an LTS will bump to the next “dot
│ │ │ │ │ -zero” version. For example: 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS), etc.
│ │ │ │ │ +_v_e_r_s_i_o_n_i_n_g such that each version following an LTS will bump to the next «dot
│ │ │ │ │ +zero» version. For example: 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS), etc.
│ │ │ │ │ SemVer makes it easier to see at a glance how compatible releases are with each
│ │ │ │ │ other. It also helps to anticipate when compatibility shims will be removed.
│ │ │ │ │ It’s not a pure form of SemVer as each feature release will continue to have a
│ │ │ │ │ few documented backwards incompatibilities where a deprecation path isn’t
│ │ │ │ │ possible or not worth the cost. Also, deprecations started in an LTS release
│ │ │ │ │ (X.2) will be dropped in a non-dot-zero release (Y.1) to accommodate our policy
│ │ │ │ │ of keeping deprecation shims for at least two feature releases. Read on to the
│ │ │ │ │ @@ -126,15 +126,15 @@
│ │ │ │ │ ****** PPhhaassee oonnee:: ffeeaattuurree pprrooppoossaall_?¶ ******
│ │ │ │ │ The first phase of the release process will include figuring out what major
│ │ │ │ │ features to include in the next version. This should include a good deal of
│ │ │ │ │ preliminary work on those features – working code trumps grand design.
│ │ │ │ │ Major features for an upcoming release will be added to the wiki roadmap page,
│ │ │ │ │ e.g. _h_t_t_p_s_:_/_/_c_o_d_e_._d_j_a_n_g_o_p_r_o_j_e_c_t_._c_o_m_/_w_i_k_i_/_V_e_r_s_i_o_n_1_._1_1_R_o_a_d_m_a_p.
│ │ │ │ │ ****** PPhhaassee ttwwoo:: ddeevveellooppmmeenntt_?¶ ******
│ │ │ │ │ -The second part of the release schedule is the “heads-down” working period.
│ │ │ │ │ +The second part of the release schedule is the «heads-down» working period.
│ │ │ │ │ Using the roadmap produced at the end of phase one, we’ll all work very hard to
│ │ │ │ │ get everything on it done.
│ │ │ │ │ At the end of phase two, any unfinished features will be postponed until the
│ │ │ │ │ next release.
│ │ │ │ │ Phase two will culminate with an alpha release. At this point, the stable/A.B.x
│ │ │ │ │ branch will be forked from main.
│ │ │ │ │ ****** PPhhaassee tthhrreeee:: bbuuggffiixxeess_?¶ ******
│ │ │ │ │ @@ -165,16 +165,16 @@
│ │ │ │ │ o _S_u_p_p_o_r_t_e_d_ _v_e_r_s_i_o_n_s
│ │ │ │ │ o _R_e_l_e_a_s_e_ _p_r_o_c_e_s_s
│ │ │ │ │ # _R_e_l_e_a_s_e_ _c_y_c_l_e
│ │ │ │ │ # _P_h_a_s_e_ _o_n_e_:_ _f_e_a_t_u_r_e_ _p_r_o_p_o_s_a_l
│ │ │ │ │ # _P_h_a_s_e_ _t_w_o_:_ _d_e_v_e_l_o_p_m_e_n_t
│ │ │ │ │ # _P_h_a_s_e_ _t_h_r_e_e_:_ _b_u_g_f_i_x_e_s
│ │ │ │ │ # _B_u_g_-_f_i_x_ _r_e_l_e_a_s_e_s
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _D_j_a_n_g_o_’_s_ _s_e_c_u_r_i_t_y_ _p_o_l_i_c_i_e_s
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _D_j_a_n_g_o_ _D_e_p_r_e_c_a_t_i_o_n_ _T_i_m_e_l_i_n_e
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/internals/security.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Django’s security policies — Django 5.1b1 documentation
│ │ │ │ + Django’s security policies — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,15 +54,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
If you believe that you, or an organization you are authorized to
│ │ │ │ represent, fall into one of the groups listed above, you can ask to be
│ │ │ │ added to Django’s notification list by emailing
│ │ │ │ -security@djangoproject.com. Please use the subject line “Security
│ │ │ │ -notification request”.
│ │ │ │ +security@djangoproject.com. Please use the subject line «Security
│ │ │ │ +notification request».
│ │ │ │
Your request must include the following information:
│ │ │ │
│ │ │ │
Your full, real name and the name of the organization you represent,
│ │ │ │ if applicable, as well as your role within that organization.
│ │ │ │
A detailed explanation of how you or your organization fit at least
│ │ │ │ one set of criteria listed above.
│ │ │ │
A detailed explanation of why you are requesting security notifications.
│ │ │ │ @@ -301,37 +302,37 @@
│ │ │ │
Contributing back to Django itself is the best way to see your own concerns
│ │ │ │ addressed. This may seem daunting at first, but it’s a well-traveled path with
│ │ │ │ documentation, tooling, and a community to support you. We’ll walk you through
│ │ │ │ the entire process, so you can learn by example.
If you are looking for a reference on the details of making code
│ │ │ │ contributions, see the Contributing code
│ │ │ │ documentation.
│ │ │ │
│ │ │ │
For this tutorial, we expect that you have at least a basic understanding of
│ │ │ │ how Django works. This means you should be comfortable going through the
│ │ │ │ existing tutorials on writing your first Django app.
│ │ │ │ @@ -346,31 +347,31 @@
│ │ │ │ is the database backend for the default settings. To run the tests using a
│ │ │ │ different backend, see Using another settings module.
│ │ │ │
Once the tests complete, you should be greeted with a message informing you
│ │ │ │ whether the test suite passed or failed. Since you haven’t yet made any changes
│ │ │ │ to Django’s code, the entire test suite should pass. If you get failures or
│ │ │ │ errors make sure you’ve followed all of the previous steps properly. See
│ │ │ │ Running the unit tests for more information.
│ │ │ │ -
Note that the latest Django “main” branch may not always be stable. When
│ │ │ │ -developing against “main”, you can check Django’s continuous integration
│ │ │ │ +
For this tutorial and the ticket we’re working on, testing against SQLite
│ │ │ │ is sufficient, however, it’s possible (and sometimes necessary) to
│ │ │ │ run the tests using a different database. When making UI changes, you will need to
│ │ │ │ run the Selenium tests.
For this tutorial, we’ll work on a “fake ticket” as a case study. Here are the
│ │ │ │ +
For this tutorial, we’ll work on a «fake ticket» as a case study. Here are the
│ │ │ │ imaginary details:
│ │ │ │
│ │ │ │
Ticket #99999 – Allow making toast
│ │ │ │
Django should provide a function django.shortcuts.make_toast() that
│ │ │ │ returns 'toast'.
│ │ │ │
│ │ │ │
We’ll now implement this feature and associated tests.
│ │ │ │ @@ -389,15 +390,15 @@
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
...\> git checkout -b ticket_99999
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ -
You can choose any name that you want for the branch, “ticket_99999” is an
│ │ │ │ +
You can choose any name that you want for the branch, «ticket_99999» is an
│ │ │ │ example. All changes made in this branch will be specific to the ticket and
│ │ │ │ won’t affect the main copy of the code that we cloned earlier.
In most cases, for a contribution to be accepted into Django it has to include
│ │ │ │ tests. For bug fix contributions, this means writing a regression test to
│ │ │ │ @@ -546,15 +547,15 @@
│ │ │ │
│ │ │ │ Returns ``'toast'``.
│ │ │ │
│ │ │ │
│ │ │ │
Since this new feature will be in an upcoming release it is also added to the
│ │ │ │ release notes for the next version of Django. Open the release notes for the
│ │ │ │ latest version in docs/releases/, which at time of writing is 2.2.txt.
│ │ │ │ -Add a note under the “Minor Features” header:
│ │ │ │ +Add a note under the «Minor Features» header:
│ │ │ │
:mod:`django.shortcuts`
│ │ │ │ ~~~~~~~~~~~~~~~~~~~~~~~
│ │ │ │
│ │ │ │ * The new :func:`django.shortcuts.make_toast` function returns ``'toast'``.
│ │ │ │
│ │ │ │
│ │ │ │
For more information on writing documentation, including an explanation of what
│ │ │ │ @@ -687,15 +688,15 @@
│ │ │ │
Fixed #99999 -- Added a shortcut function to make toast.
│ │ │ │
You can create a pull request by visiting the Django GitHub page. You’ll see your branch under “Your
│ │ │ │ -recently pushed branches”. Click “Compare & pull request” next to it.
│ │ │ │ +
You can create a pull request by visiting the Django GitHub page. You’ll see your branch under «Your
│ │ │ │ +recently pushed branches». Click «Compare & pull request» next to it.
│ │ │ │
Please don’t do it for this tutorial, but on the next page that displays a
│ │ │ │ -preview of the changes, you would click “Create pull request”.
│ │ │ │ +preview of the changes, you would click «Create pull request».
│ │ │ │
│ │ │ │
│ │ │ │
Congratulations, you’ve learned how to make a pull request to Django! Details
│ │ │ │ of more advanced techniques you may need are in
│ │ │ │ Working with Git and GitHub.
│ │ │ │
Now you can put those skills to good use by helping to improve Django’s
│ │ │ │ @@ -739,15 +740,15 @@
│ │ │ │ for answering any questions you might have.
Once you’ve looked through some of that information, you’ll be ready to go out
│ │ │ │ and find a ticket of your own to contribute to. Pay special attention to
│ │ │ │ -tickets with the “easy pickings” criterion. These tickets are often much
│ │ │ │ +tickets with the «easy pickings» criterion. These tickets are often much
│ │ │ │ simpler in nature and are great for first time contributors. Once you’re
│ │ │ │ familiar with contributing to Django, you can start working on more difficult
│ │ │ │ and complicated tickets.
After a ticket has a branch, it needs to be reviewed by a second set of eyes.
│ │ │ │ After submitting a pull request, update the ticket metadata by setting the
│ │ │ │ -flags on the ticket to say “has patch”, “doesn’t need tests”, etc, so others
│ │ │ │ +flags on the ticket to say «has patch», «doesn’t need tests», etc, so others
│ │ │ │ can find it for review. Contributing doesn’t necessarily always mean writing
│ │ │ │ code from scratch. Reviewing open pull requests is also a very helpful
│ │ │ │ contribution. See Triaging tickets for details.
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,21 +1,21 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ WWrriittiinngg yyoouurr ffiirrsstt ccoonnttrriibbuuttiioonn ffoorr DDjjaannggoo_?¶ ************
│ │ │ │ │ ********** IInnttrroodduuccttiioonn_?¶ **********
│ │ │ │ │ Interested in giving back to the community a little? Maybe you’ve found a bug
│ │ │ │ │ in Django that you’d like to see fixed, or maybe there’s a small feature you
│ │ │ │ │ want added.
│ │ │ │ │ Contributing back to Django itself is the best way to see your own concerns
│ │ │ │ │ addressed. This may seem daunting at first, but it’s a well-traveled path with
│ │ │ │ │ documentation, tooling, and a community to support you. We’ll walk you through
│ │ │ │ │ the entire process, so you can learn by example.
│ │ │ │ │ ******** WWhhoo?’ss tthhiiss ttuuttoorriiaall ffoorr??_?¶ ********
│ │ │ │ │ -See also
│ │ │ │ │ +Vedi anche
│ │ │ │ │ If you are looking for a reference on the details of making code contributions,
│ │ │ │ │ see the _C_o_n_t_r_i_b_u_t_i_n_g_ _c_o_d_e documentation.
│ │ │ │ │ For this tutorial, we expect that you have at least a basic understanding of
│ │ │ │ │ how Django works. This means you should be comfortable going through the
│ │ │ │ │ existing tutorials on _w_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _D_j_a_n_g_o_ _a_p_p. In addition, you should
│ │ │ │ │ have a good understanding of Python itself. But if you don’t, _D_i_v_e_ _I_n_t_o_ _P_y_t_h_o_n
│ │ │ │ │ is a fantastic (and free) online book for beginning Python programmers.
│ │ │ │ │ @@ -152,38 +152,38 @@
│ │ │ │ │ backend for the default settings. To run the tests using a different backend,
│ │ │ │ │ see _U_s_i_n_g_ _a_n_o_t_h_e_r_ _s_e_t_t_i_n_g_s_ _m_o_d_u_l_e.
│ │ │ │ │ Once the tests complete, you should be greeted with a message informing you
│ │ │ │ │ whether the test suite passed or failed. Since you haven’t yet made any changes
│ │ │ │ │ to Django’s code, the entire test suite sshhoouulldd pass. If you get failures or
│ │ │ │ │ errors make sure you’ve followed all of the previous steps properly. See
│ │ │ │ │ _R_u_n_n_i_n_g_ _t_h_e_ _u_n_i_t_ _t_e_s_t_s for more information.
│ │ │ │ │ -Note that the latest Django “main” branch may not always be stable. When
│ │ │ │ │ -developing against “main”, you can check _D_j_a_n_g_o_’_s_ _c_o_n_t_i_n_u_o_u_s_ _i_n_t_e_g_r_a_t_i_o_n_ _b_u_i_l_d_s
│ │ │ │ │ +Note that the latest Django «main» branch may not always be stable. When
│ │ │ │ │ +developing against «main», you can check _D_j_a_n_g_o_’_s_ _c_o_n_t_i_n_u_o_u_s_ _i_n_t_e_g_r_a_t_i_o_n_ _b_u_i_l_d_s
│ │ │ │ │ to determine if the failures are specific to your machine or if they are also
│ │ │ │ │ present in Django’s official builds. If you click to view a particular build,
│ │ │ │ │ -you can view the “Configuration Matrix” which shows failures broken down by
│ │ │ │ │ +you can view the «Configuration Matrix» which shows failures broken down by
│ │ │ │ │ Python version and database backend.
│ │ │ │ │ -Note
│ │ │ │ │ +Nota
│ │ │ │ │ For this tutorial and the ticket we’re working on, testing against SQLite is
│ │ │ │ │ sufficient, however, it’s possible (and sometimes necessary) to _r_u_n_ _t_h_e_ _t_e_s_t_s
│ │ │ │ │ _u_s_i_n_g_ _a_ _d_i_f_f_e_r_e_n_t_ _d_a_t_a_b_a_s_e. When making UI changes, you will need to _r_u_n_ _t_h_e
│ │ │ │ │ _S_e_l_e_n_i_u_m_ _t_e_s_t_s.
│ │ │ │ │ ********** WWoorrkkiinngg oonn aa ffeeaattuurree_?¶ **********
│ │ │ │ │ -For this tutorial, we’ll work on a “fake ticket” as a case study. Here are the
│ │ │ │ │ +For this tutorial, we’ll work on a «fake ticket» as a case study. Here are the
│ │ │ │ │ imaginary details:
│ │ │ │ │ Ticket #99999 – Allow making toast
│ │ │ │ │ Django should provide a function django.shortcuts.make_toast() that returns
│ │ │ │ │ 'toast'.
│ │ │ │ │ We’ll now implement this feature and associated tests.
│ │ │ │ │ ********** CCrreeaattiinngg aa bbrraanncchh_?¶ **********
│ │ │ │ │ Before making any changes, create a new branch for the ticket:
│ │ │ │ │ #/ o
│ │ │ │ │ $ git checkout -b ticket_99999
│ │ │ │ │ ...\> git checkout -b ticket_99999
│ │ │ │ │ -You can choose any name that you want for the branch, “ticket_99999” is an
│ │ │ │ │ +You can choose any name that you want for the branch, «ticket_99999» is an
│ │ │ │ │ example. All changes made in this branch will be specific to the ticket and
│ │ │ │ │ won’t affect the main copy of the code that we cloned earlier.
│ │ │ │ │ ********** WWrriittiinngg ssoommee tteessttss ffoorr yyoouurr ttiicckkeett_?¶ **********
│ │ │ │ │ In most cases, for a contribution to be accepted into Django it has to include
│ │ │ │ │ tests. For bug fix contributions, this means writing a regression test to
│ │ │ │ │ ensure that the bug is never reintroduced into Django later on. A regression
│ │ │ │ │ test should be written in such a way that it will fail while the bug still
│ │ │ │ │ @@ -271,15 +271,15 @@
│ │ │ │ │
│ │ │ │ │ .. versionadded:: 2.2
│ │ │ │ │
│ │ │ │ │ Returns ``'toast'``.
│ │ │ │ │ Since this new feature will be in an upcoming release it is also added to the
│ │ │ │ │ release notes for the next version of Django. Open the release notes for the
│ │ │ │ │ latest version in docs/releases/, which at time of writing is 2.2.txt. Add a
│ │ │ │ │ -note under the “Minor Features” header:
│ │ │ │ │ +note under the «Minor Features» header:
│ │ │ │ │ :mod:`django.shortcuts`
│ │ │ │ │ ~~~~~~~~~~~~~~~~~~~~~~~
│ │ │ │ │
│ │ │ │ │ * The new :func:`django.shortcuts.make_toast` function returns ``'toast'``.
│ │ │ │ │ For more information on writing documentation, including an explanation of what
│ │ │ │ │ the versionadded bit is all about, see _W_r_i_t_i_n_g_ _d_o_c_u_m_e_n_t_a_t_i_o_n. That page also
│ │ │ │ │ includes an explanation of how to build a copy of the documentation locally, so
│ │ │ │ │ @@ -365,23 +365,23 @@
│ │ │ │ │ $ git commit
│ │ │ │ │ ...\> git commit
│ │ │ │ │ This opens up a text editor to type the commit message. Follow the _c_o_m_m_i_t
│ │ │ │ │ _m_e_s_s_a_g_e_ _g_u_i_d_e_l_i_n_e_s and write a message like:
│ │ │ │ │ Fixed #99999 -- Added a shortcut function to make toast.
│ │ │ │ │ ********** PPuusshhiinngg tthhee ccoommmmiitt aanndd mmaakkiinngg aa ppuullll rreeqquueesstt_?¶ **********
│ │ │ │ │ After committing the changes, send it to your fork on GitHub (substitute
│ │ │ │ │ -“ticket_99999” with the name of your branch if it’s different):
│ │ │ │ │ +«ticket_99999» with the name of your branch if it’s different):
│ │ │ │ │ #/ o
│ │ │ │ │ $ git push origin ticket_99999
│ │ │ │ │ ...\> git push origin ticket_99999
│ │ │ │ │ You can create a pull request by visiting the _D_j_a_n_g_o_ _G_i_t_H_u_b_ _p_a_g_e. You’ll see
│ │ │ │ │ -your branch under “Your recently pushed branches”. Click “Compare & pull
│ │ │ │ │ -request” next to it.
│ │ │ │ │ +your branch under «Your recently pushed branches». Click «Compare & pull
│ │ │ │ │ +request» next to it.
│ │ │ │ │ Please don’t do it for this tutorial, but on the next page that displays a
│ │ │ │ │ -preview of the changes, you would click “Create pull request”.
│ │ │ │ │ +preview of the changes, you would click «Create pull request».
│ │ │ │ │ ********** NNeexxtt sstteeppss_?¶ **********
│ │ │ │ │ Congratulations, you’ve learned how to make a pull request to Django! Details
│ │ │ │ │ of more advanced techniques you may need are in _W_o_r_k_i_n_g_ _w_i_t_h_ _G_i_t_ _a_n_d_ _G_i_t_H_u_b.
│ │ │ │ │ Now you can put those skills to good use by helping to improve Django’s
│ │ │ │ │ codebase.
│ │ │ │ │ ******** MMoorree iinnffoorrmmaattiioonn ffoorr nneeww ccoonnttrriibbuuttoorrss_?¶ ********
│ │ │ │ │ Before you get too into contributing to Django, there’s a little more
│ │ │ │ │ @@ -397,28 +397,28 @@
│ │ │ │ │ contributing, you can always browse through the rest of _D_j_a_n_g_o_’_s
│ │ │ │ │ _d_o_c_u_m_e_n_t_a_t_i_o_n_ _o_n_ _c_o_n_t_r_i_b_u_t_i_n_g. It contains a ton of useful information
│ │ │ │ │ and should be your first source for answering any questions you might
│ │ │ │ │ have.
│ │ │ │ │ ******** FFiinnddiinngg yyoouurr ffiirrsstt rreeaall ttiicckkeett_?¶ ********
│ │ │ │ │ Once you’ve looked through some of that information, you’ll be ready to go out
│ │ │ │ │ and find a ticket of your own to contribute to. Pay special attention to
│ │ │ │ │ -tickets with the “easy pickings” criterion. These tickets are often much
│ │ │ │ │ +tickets with the «easy pickings» criterion. These tickets are often much
│ │ │ │ │ simpler in nature and are great for first time contributors. Once you’re
│ │ │ │ │ familiar with contributing to Django, you can start working on more difficult
│ │ │ │ │ and complicated tickets.
│ │ │ │ │ If you just want to get started already (and nobody would blame you!), try
│ │ │ │ │ taking a look at the list of _e_a_s_y_ _t_i_c_k_e_t_s_ _w_i_t_h_o_u_t_ _a_ _b_r_a_n_c_h and the _e_a_s_y_ _t_i_c_k_e_t_s
│ │ │ │ │ _t_h_a_t_ _h_a_v_e_ _b_r_a_n_c_h_e_s_ _w_h_i_c_h_ _n_e_e_d_ _i_m_p_r_o_v_e_m_e_n_t. If you’re familiar with writing
│ │ │ │ │ tests, you can also look at the list of _e_a_s_y_ _t_i_c_k_e_t_s_ _t_h_a_t_ _n_e_e_d_ _t_e_s_t_s. Remember
│ │ │ │ │ to follow the guidelines about claiming tickets that were mentioned in the link
│ │ │ │ │ to Django’s documentation on _c_l_a_i_m_i_n_g_ _t_i_c_k_e_t_s_ _a_n_d_ _s_u_b_m_i_t_t_i_n_g_ _b_r_a_n_c_h_e_s.
│ │ │ │ │ ******** WWhhaatt?’ss nneexxtt aafftteerr ccrreeaattiinngg aa ppuullll rreeqquueesstt??_?¶ ********
│ │ │ │ │ After a ticket has a branch, it needs to be reviewed by a second set of eyes.
│ │ │ │ │ After submitting a pull request, update the ticket metadata by setting the
│ │ │ │ │ -flags on the ticket to say “has patch”, “doesn’t need tests”, etc, so others
│ │ │ │ │ +flags on the ticket to say «has patch», «doesn’t need tests», etc, so others
│ │ │ │ │ can find it for review. Contributing doesn’t necessarily always mean writing
│ │ │ │ │ code from scratch. Reviewing open pull requests is also a very helpful
│ │ │ │ │ contribution. See _T_r_i_a_g_i_n_g_ _t_i_c_k_e_t_s for details.
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ * _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _c_o_n_t_r_i_b_u_t_i_o_n_ _f_o_r_ _D_j_a_n_g_o
│ │ │ │ │ o _I_n_t_r_o_d_u_c_t_i_o_n
│ │ │ │ │ # _W_h_o_’_s_ _t_h_i_s_ _t_u_t_o_r_i_a_l_ _f_o_r_?
│ │ │ │ │ @@ -439,16 +439,16 @@
│ │ │ │ │ o _P_r_e_v_i_e_w_i_n_g_ _y_o_u_r_ _c_h_a_n_g_e_s
│ │ │ │ │ o _C_o_m_m_i_t_t_i_n_g_ _t_h_e_ _c_h_a_n_g_e_s
│ │ │ │ │ o _P_u_s_h_i_n_g_ _t_h_e_ _c_o_m_m_i_t_ _a_n_d_ _m_a_k_i_n_g_ _a_ _p_u_l_l_ _r_e_q_u_e_s_t
│ │ │ │ │ o _N_e_x_t_ _s_t_e_p_s
│ │ │ │ │ # _M_o_r_e_ _i_n_f_o_r_m_a_t_i_o_n_ _f_o_r_ _n_e_w_ _c_o_n_t_r_i_b_u_t_o_r_s
│ │ │ │ │ # _F_i_n_d_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _r_e_a_l_ _t_i_c_k_e_t
│ │ │ │ │ # _W_h_a_t_’_s_ _n_e_x_t_ _a_f_t_e_r_ _c_r_e_a_t_i_n_g_ _a_ _p_u_l_l_ _r_e_q_u_e_s_t_?
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _W_h_a_t_ _t_o_ _r_e_a_d_ _n_e_x_t
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _U_s_i_n_g_ _D_j_a_n_g_o
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/intro/index.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Getting started — Django 5.1b1 documentation
│ │ │ │ + Getting started — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,25 +54,25 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
If you’re new to Python, you might want to start by getting an idea of what
│ │ │ │ the language is like. Django is 100% Python, so if you’ve got minimal
│ │ │ │ comfort with Python you’ll probably get a lot more out of Django.
If you already know a few other languages and want to get up to speed with
│ │ │ │ Python quickly, we recommend referring the official
│ │ │ │ @@ -120,47 +121,47 @@
│ │ │ │
│ │ │ │
│ │ │ │
This step is only necessary if you’d like to work with a “large” database engine
│ │ │ │ +
This step is only necessary if you’d like to work with a «large» database engine
│ │ │ │ like PostgreSQL, MariaDB, MySQL, or Oracle. To install such a database, consult
│ │ │ │ the database installation information.
Although you can use Django without a database, it comes with an
│ │ │ │ object-relational mapper in which you describe your database layout in Python
│ │ │ │ code.
│ │ │ │
The data-model syntax offers many rich ways of
│ │ │ │ -representing your models – so far, it’s been solving many years’ worth of
│ │ │ │ +representing your models – so far, it’s been solving many years” worth of
│ │ │ │ database-schema problems. Here’s a quick example:
The code above maps URL paths to Python callback functions (“views”). The path
│ │ │ │ -strings use parameter tags to “capture” values from the URLs. When a user
│ │ │ │ +
The code above maps URL paths to Python callback functions («views»). The path
│ │ │ │ +strings use parameter tags to «capture» values from the URLs. When a user
│ │ │ │ requests a page, Django runs through each path, in order, and stops at the
│ │ │ │ first one that matches the requested URL. (If none of them matches, Django
│ │ │ │ calls a special-case 404 view.) This is blazingly fast, because the paths are
│ │ │ │ compiled into regular expressions at load time.
│ │ │ │
Once one of the URL patterns matches, Django calls the given view, which is a
│ │ │ │ Python function. Each view gets passed a request object – which contains
│ │ │ │ request metadata – and the values captured in the pattern.
│ │ │ │ -
For example, if a user requested the URL “/articles/2005/05/39323/”, Django
│ │ │ │ +
For example, if a user requested the URL «/articles/2005/05/39323/», Django
│ │ │ │ would call the function news.views.article_detail(request,
│ │ │ │ year=2005,month=5,pk=39323).
Each view is responsible for doing one of two things: Returning an
│ │ │ │ HttpResponse object containing the content for the
│ │ │ │ @@ -359,31 +360,31 @@
│ │ │ │ <p>Published {{article.pub_date|date:"F j, Y"}}</p>
│ │ │ │ {%endfor%}
│ │ │ │ {%endblock%}
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Variables are surrounded by double-curly braces. {{article.headline}}
│ │ │ │ -means “Output the value of the article’s headline attribute.” But dots aren’t
│ │ │ │ +means «Output the value of the article’s headline attribute.» But dots aren’t
│ │ │ │ used only for attribute lookup. They also can do dictionary-key lookup, index
│ │ │ │ lookup and function calls.
│ │ │ │ -
Note {{article.pub_date|date:"Fj,Y"}} uses a Unix-style “pipe” (the “|”
│ │ │ │ +
Note {{article.pub_date|date:"Fj,Y"}} uses a Unix-style «pipe» (the «|»
│ │ │ │ character). This is called a template filter, and it’s a way to filter the value
│ │ │ │ of a variable. In this case, the date filter formats a Python datetime object in
│ │ │ │ the given format (as found in PHP’s date function).
Finally, Django uses the concept of “template inheritance”. That’s what the
│ │ │ │ -{%extends"base.html"%} does. It means “First load the template called
│ │ │ │ -‘base’, which has defined a bunch of blocks, and fill the blocks with the
│ │ │ │ -following blocks.” In short, that lets you dramatically cut down on redundancy
│ │ │ │ +
Finally, Django uses the concept of «template inheritance». That’s what the
│ │ │ │ +{%extends"base.html"%} does. It means «First load the template called
│ │ │ │ +“base”, which has defined a bunch of blocks, and fill the blocks with the
│ │ │ │ +following blocks.» In short, that lets you dramatically cut down on redundancy
│ │ │ │ in templates: each template has to define only what’s unique to that template.
│ │ │ │ -
Here’s what the “base.html” template, including the use of static files, might look like:
│ │ │ │ +
Here’s what the «base.html» template, including the use of static files, might look like:
Simplistically, it defines the look-and-feel of the site (with the site’s logo),
│ │ │ │ -and provides “holes” for child templates to fill. This means that a site redesign
│ │ │ │ +and provides «holes» for child templates to fill. This means that a site redesign
│ │ │ │ can be done by changing a single file – the base template.
│ │ │ │
It also lets you create multiple versions of a site, with different base
│ │ │ │ templates, while reusing child templates. Django’s creators have used this
│ │ │ │ technique to create strikingly different mobile versions of sites by only
│ │ │ │ creating a new base template.
│ │ │ │
Note that you don’t have to use Django’s template system if you prefer another
│ │ │ │ system. While Django’s template system is particularly well-integrated with
│ │ │ │ @@ -450,37 +451,37 @@
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,23 +1,23 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ DDjjaannggoo aatt aa ggllaannccee_?¶ ************
│ │ │ │ │ Because Django was developed in a fast-paced newsroom environment, it was
│ │ │ │ │ designed to make common web development tasks fast and easy. Here’s an informal
│ │ │ │ │ overview of how to write a database-driven web app with Django.
│ │ │ │ │ The goal of this document is to give you enough technical specifics to
│ │ │ │ │ understand how Django works, but this isn’t intended to be a tutorial or
│ │ │ │ │ reference – but we’ve got both! When you’re ready to start a project, you can
│ │ │ │ │ _s_t_a_r_t_ _w_i_t_h_ _t_h_e_ _t_u_t_o_r_i_a_l or _d_i_v_e_ _r_i_g_h_t_ _i_n_t_o_ _m_o_r_e_ _d_e_t_a_i_l_e_d_ _d_o_c_u_m_e_n_t_a_t_i_o_n.
│ │ │ │ │ ********** DDeessiiggnn yyoouurr mmooddeell_?¶ **********
│ │ │ │ │ Although you can use Django without a database, it comes with an _o_b_j_e_c_t_-
│ │ │ │ │ _r_e_l_a_t_i_o_n_a_l_ _m_a_p_p_e_r in which you describe your database layout in Python code.
│ │ │ │ │ The _d_a_t_a_-_m_o_d_e_l_ _s_y_n_t_a_x offers many rich ways of representing your models – so
│ │ │ │ │ -far, it’s been solving many years’ worth of database-schema problems. Here’s a
│ │ │ │ │ +far, it’s been solving many years” worth of database-schema problems. Here’s a
│ │ │ │ │ quick example:
│ │ │ │ │ mysite/news/models.py_¶
│ │ │ │ │ from django.db import models
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ class Reporter(models.Model):
│ │ │ │ │ full_name = models.CharField(max_length=70)
│ │ │ │ │ @@ -160,24 +160,24 @@
│ │ │ │ │ from . import views
│ │ │ │ │
│ │ │ │ │ urlpatterns = [
│ │ │ │ │ path("articles//", views.year_archive),
│ │ │ │ │ path("articles///", views.month_archive),
│ │ │ │ │ path("articles////", views.article_detail),
│ │ │ │ │ ]
│ │ │ │ │ -The code above maps URL paths to Python callback functions (“views”). The path
│ │ │ │ │ -strings use parameter tags to “capture” values from the URLs. When a user
│ │ │ │ │ +The code above maps URL paths to Python callback functions («views»). The path
│ │ │ │ │ +strings use parameter tags to «capture» values from the URLs. When a user
│ │ │ │ │ requests a page, Django runs through each path, in order, and stops at the
│ │ │ │ │ first one that matches the requested URL. (If none of them matches, Django
│ │ │ │ │ calls a special-case 404 view.) This is blazingly fast, because the paths are
│ │ │ │ │ compiled into regular expressions at load time.
│ │ │ │ │ Once one of the URL patterns matches, Django calls the given view, which is a
│ │ │ │ │ Python function. Each view gets passed a request object – which contains
│ │ │ │ │ request metadata – and the values captured in the pattern.
│ │ │ │ │ -For example, if a user requested the URL “/articles/2005/05/39323/”, Django
│ │ │ │ │ +For example, if a user requested the URL «/articles/2005/05/39323/», Django
│ │ │ │ │ would call the function news.views.article_detail(request, year=2005, month=5,
│ │ │ │ │ pk=39323).
│ │ │ │ │ ********** WWrriittee yyoouurr vviieewwss_?¶ **********
│ │ │ │ │ Each view is responsible for doing one of two things: Returning an _H_t_t_p_R_e_s_p_o_n_s_e
│ │ │ │ │ object containing the content for the requested page, or raising an exception
│ │ │ │ │ such as _H_t_t_p_4_0_4. The rest is up to you.
│ │ │ │ │ Generally, a view retrieves data according to the parameters, loads a template
│ │ │ │ │ @@ -214,44 +214,44 @@
│ │ │ │ │ {% for article in article_list %}
│ │ │ │ │
{{ article.headline }}
│ │ │ │ │
By {{ article.reporter.full_name }}
│ │ │ │ │
Published {{ article.pub_date|date:"F j, Y" }}
│ │ │ │ │ {% endfor %}
│ │ │ │ │ {% endblock %}
│ │ │ │ │ Variables are surrounded by double-curly braces. {{ article.headline }} means
│ │ │ │ │ -“Output the value of the article’s headline attribute.” But dots aren’t used
│ │ │ │ │ +«Output the value of the article’s headline attribute.» But dots aren’t used
│ │ │ │ │ only for attribute lookup. They also can do dictionary-key lookup, index lookup
│ │ │ │ │ and function calls.
│ │ │ │ │ -Note {{ article.pub_date|date:"F j, Y" }} uses a Unix-style “pipe” (the “|”
│ │ │ │ │ +Note {{ article.pub_date|date:"F j, Y" }} uses a Unix-style «pipe» (the «|»
│ │ │ │ │ character). This is called a template filter, and it’s a way to filter the
│ │ │ │ │ value of a variable. In this case, the date filter formats a Python datetime
│ │ │ │ │ object in the given format (as found in PHP’s date function).
│ │ │ │ │ You can chain together as many filters as you’d like. You can write _c_u_s_t_o_m
│ │ │ │ │ _t_e_m_p_l_a_t_e_ _f_i_l_t_e_r_s. You can write _c_u_s_t_o_m_ _t_e_m_p_l_a_t_e_ _t_a_g_s, which run custom Python
│ │ │ │ │ code behind the scenes.
│ │ │ │ │ -Finally, Django uses the concept of “template inheritance”. That’s what the {%
│ │ │ │ │ -extends "base.html" %} does. It means “First load the template called ‘base’,
│ │ │ │ │ +Finally, Django uses the concept of «template inheritance». That’s what the {%
│ │ │ │ │ +extends "base.html" %} does. It means «First load the template called “base”,
│ │ │ │ │ which has defined a bunch of blocks, and fill the blocks with the following
│ │ │ │ │ -blocks.” In short, that lets you dramatically cut down on redundancy in
│ │ │ │ │ +blocks.» In short, that lets you dramatically cut down on redundancy in
│ │ │ │ │ templates: each template has to define only what’s unique to that template.
│ │ │ │ │ -Here’s what the “base.html” template, including the use of _s_t_a_t_i_c_ _f_i_l_e_s, might
│ │ │ │ │ +Here’s what the «base.html» template, including the use of _s_t_a_t_i_c_ _f_i_l_e_s, might
│ │ │ │ │ look like:
│ │ │ │ │ mysite/templates/base.html_¶
│ │ │ │ │ {% load static %}
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ {% block title %}{% endblock %}
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ {% block content %}{% endblock %}
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ Simplistically, it defines the look-and-feel of the site (with the site’s
│ │ │ │ │ -logo), and provides “holes” for child templates to fill. This means that a site
│ │ │ │ │ +logo), and provides «holes» for child templates to fill. This means that a site
│ │ │ │ │ redesign can be done by changing a single file – the base template.
│ │ │ │ │ It also lets you create multiple versions of a site, with different base
│ │ │ │ │ templates, while reusing child templates. Django’s creators have used this
│ │ │ │ │ technique to create strikingly different mobile versions of sites by only
│ │ │ │ │ creating a new base template.
│ │ │ │ │ Note that you don’t have to use Django’s template system if you prefer another
│ │ │ │ │ system. While Django’s template system is particularly well-integrated with
│ │ │ │ │ @@ -277,16 +277,16 @@
│ │ │ │ │ o _E_n_j_o_y_ _t_h_e_ _f_r_e_e_ _A_P_I
│ │ │ │ │ o _A_ _d_y_n_a_m_i_c_ _a_d_m_i_n_ _i_n_t_e_r_f_a_c_e_:_ _i_t_’_s_ _n_o_t_ _j_u_s_t_ _s_c_a_f_f_o_l_d_i_n_g_ _–_ _i_t_’_s_ _t_h_e
│ │ │ │ │ _w_h_o_l_e_ _h_o_u_s_e
│ │ │ │ │ o _D_e_s_i_g_n_ _y_o_u_r_ _U_R_L_s
│ │ │ │ │ o _W_r_i_t_e_ _y_o_u_r_ _v_i_e_w_s
│ │ │ │ │ o _D_e_s_i_g_n_ _y_o_u_r_ _t_e_m_p_l_a_t_e_s
│ │ │ │ │ o _T_h_i_s_ _i_s_ _j_u_s_t_ _t_h_e_ _s_u_r_f_a_c_e
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _G_e_t_t_i_n_g_ _s_t_a_r_t_e_d
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _Q_u_i_c_k_ _i_n_s_t_a_l_l_ _g_u_i_d_e
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/intro/reusable-apps.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Advanced tutorial: How to write reusable apps — Django 5.1b1 documentation
│ │ │ │ + Advanced tutorial: How to write reusable apps — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,15 +54,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -101,15 +102,15 @@
│ │ │ │ could decouple polls from the project-level URLconf using an include.
│ │ │ │ In this tutorial, we’ll take further steps to make the app easy to use in new
│ │ │ │ projects and ready to publish for others to install and use.
│ │ │ │
│ │ │ │
Package? App?
│ │ │ │
A Python package provides a way of grouping related Python code for
│ │ │ │ easy reuse. A package contains one or more files of Python code (also known
│ │ │ │ -as “modules”).
│ │ │ │ +as «modules»).
│ │ │ │
A package can be imported with importfoo.bar or fromfooimport
│ │ │ │ bar. For a directory (like polls) to form a package, it must contain
│ │ │ │ a special file __init__.py, even if this file is empty.
│ │ │ │
A Django application is a Python package that is specifically intended
│ │ │ │ for use in a Django project. An application may use common Django
│ │ │ │ conventions, such as having models, tests, urls, and views
│ │ │ │ submodules.
If Django is installed, you should see the version of your installation. If it
│ │ │ │ -isn’t, you’ll get an error telling “No module named django”.
│ │ │ │ +isn’t, you’ll get an error telling «No module named django».
│ │ │ │
This tutorial is written for Django 5.1, which supports Python 3.10 and
│ │ │ │ later. If the Django version doesn’t match, you can refer to the tutorial for
│ │ │ │ your version of Django by using the version switcher at the bottom right corner
│ │ │ │ of this page, or update Django to the newest version. If you’re using an older
│ │ │ │ version of Python, check What Python version can I use with Django? to find a compatible
│ │ │ │ version of Django.
│ │ │ │
See How to install Django for advice on how to remove
│ │ │ │ @@ -156,15 +157,15 @@
│ │ │ │
...\> django-admin startproject mysite
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
This will create a mysite directory in your current directory. If it didn’t
│ │ │ │ work, see Problems running django-admin.
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
You’ll need to avoid naming projects after built-in Python or Django
│ │ │ │ components. In particular, this means you should avoid using names like
│ │ │ │ django (which will conflict with Django itself) or test (which
│ │ │ │ conflicts with a built-in Python package).
mysite/__init__.py: An empty file that tells Python that this
│ │ │ │ directory should be considered a Python package. If you’re a Python beginner,
│ │ │ │ read more about packages in the official Python docs.
│ │ │ │
mysite/settings.py: Settings/configuration for this Django
│ │ │ │ project. Django settings will tell you all about how settings
│ │ │ │ work.
│ │ │ │
mysite/urls.py: The URL declarations for this Django project; a
│ │ │ │ -“table of contents” of your Django-powered site. You can read more about
│ │ │ │ +«table of contents» of your Django-powered site. You can read more about
│ │ │ │ URLs in URL dispatcher.
│ │ │ │
mysite/asgi.py: An entry-point for ASGI-compatible web servers to
│ │ │ │ serve your project. See How to deploy with ASGI for more details.
│ │ │ │
mysite/wsgi.py: An entry-point for WSGI-compatible web servers to
│ │ │ │ serve your project. See How to deploy with WSGI for more details.
Performing system checks...
│ │ │ │
│ │ │ │ System check identified no issues (0 silenced).
│ │ │ │
│ │ │ │ You have unapplied migrations; your app may not work properly until they are applied.
│ │ │ │ Run 'python manage.py migrate' to apply them.
│ │ │ │
│ │ │ │ -June 26, 2024 - 15:50:53
│ │ │ │ +giugno 26, 2024 - 15:50:53
│ │ │ │ Django version 5.1, using settings 'mysite.settings'
│ │ │ │ Starting development server at http://127.0.0.1:8000/
│ │ │ │ Quit the server with CONTROL-C.
│ │ │ │
│ │ │ │ -
Note
│ │ │ │ +
Nota
│ │ │ │
Ignore the warning about unapplied database migrations for now; we’ll deal
│ │ │ │ with the database shortly.
│ │ │ │
│ │ │ │
Now that the server’s running, visit http://127.0.0.1:8000/ with your web
│ │ │ │ -browser. You’ll see a “Congratulations!” page, with a rocket taking off.
│ │ │ │ +browser. You’ll see a «Congratulations!» page, with a rocket taking off.
│ │ │ │ It worked!
│ │ │ │
You’ve started the Django development server, a lightweight web server written
│ │ │ │ purely in Python. We’ve included this with Django so you can develop things
│ │ │ │ rapidly, without having to deal with configuring a production server – such as
│ │ │ │ Apache – until you’re ready for production.
│ │ │ │
Now’s a good time to note: don’t use this server in anything resembling a
│ │ │ │ production environment. It’s intended only for use while developing. (We’re in
│ │ │ │ @@ -255,15 +256,15 @@
│ │ │ │ as needed. You don’t need to restart the server for code changes to take
│ │ │ │ effect. However, some actions like adding files don’t trigger a restart,
│ │ │ │ so you’ll have to restart the server in these cases.
Now that your environment – a “project” – is set up, you’re set to start
│ │ │ │ +
Now that your environment – a «project» – is set up, you’re set to start
│ │ │ │ doing work.
│ │ │ │
Each application you write in Django consists of a Python package that follows
│ │ │ │ a certain convention. Django comes with a utility that automatically generates
│ │ │ │ the basic directory structure of an app, so you can focus on writing code
│ │ │ │ rather than creating directories.
│ │ │ │
│ │ │ │
Projects vs. apps
│ │ │ │ @@ -368,16 +369,16 @@
│ │ │ │
│ │ │ │
The include() function allows referencing other URLconfs.
│ │ │ │ Whenever Django encounters include(), it chops off whatever
│ │ │ │ part of the URL matched up to that point and sends the remaining string to the
│ │ │ │ included URLconf for further processing.
│ │ │ │
The idea behind include() is to make it easy to
│ │ │ │ plug-and-play URLs. Since polls are in their own URLconf
│ │ │ │ -(polls/urls.py), they can be placed under “/polls/”, or under
│ │ │ │ -“/fun_polls/”, or under “/content/polls/”, or any other path root, and the
│ │ │ │ +(polls/urls.py), they can be placed under «/polls/», or under
│ │ │ │ +«/fun_polls/», or under «/content/polls/», or any other path root, and the
│ │ │ │ app will still work.
You should always use include() when you include other URL patterns.
│ │ │ │ admin.site.urls is the only exception to this.
│ │ │ │
│ │ │ │
You have now wired an index view into the URLconf. Verify it’s working with
│ │ │ │ @@ -394,15 +395,15 @@
│ │ │ │
│ │ │ │
│ │ │ │
...\> py manage.py runserver
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Go to http://localhost:8000/polls/ in your browser, and you should see the
│ │ │ │ -text “Hello, world. You’re at the polls index.”, which you defined in the
│ │ │ │ +text «Hello, world. You’re at the polls index.», which you defined in the
│ │ │ │ index view.
The path() function is passed four arguments, two required:
│ │ │ │ @@ -419,15 +420,15 @@
│ │ │ │ myapp/. In a request to https://www.example.com/myapp/?page=3, the
│ │ │ │ URLconf will also look for myapp/.
When Django finds a matching pattern, it calls the specified view function with
│ │ │ │ an HttpRequest object as the first argument and any
│ │ │ │ -“captured” values from the route as keyword arguments. We’ll give an example
│ │ │ │ +«captured» values from the route as keyword arguments. We’ll give an example
│ │ │ │ of this in a bit.
│ │ │ │ + title="capitolo successivo">Writing your first Django app, part 2
│ │ │ │
│ │ │ │
│ │ │ │ -
Quick search
│ │ │ │ +
Ricerca veloce
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Last update:
│ │ │ │ -
Jun 26, 2024
│ │ │ │ +
giu 26, 2024
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ WWrriittiinngg yyoouurr ffiirrsstt DDjjaannggoo aapppp,, ppaarrtt 11_?¶ ************
│ │ │ │ │ Let’s learn by example.
│ │ │ │ │ Throughout this tutorial, we’ll walk you through the creation of a basic poll
│ │ │ │ │ application.
│ │ │ │ │ It’ll consist of two parts:
│ │ │ │ │ @@ -11,15 +11,15 @@
│ │ │ │ │ We’ll assume you have _D_j_a_n_g_o_ _i_n_s_t_a_l_l_e_d already. You can tell Django is
│ │ │ │ │ installed and which version by running the following command in a shell prompt
│ │ │ │ │ (indicated by the $ prefix):
│ │ │ │ │ #/ o
│ │ │ │ │ $ python -m django --version
│ │ │ │ │ ...\> py -m django --version
│ │ │ │ │ If Django is installed, you should see the version of your installation. If it
│ │ │ │ │ -isn’t, you’ll get an error telling “No module named django”.
│ │ │ │ │ +isn’t, you’ll get an error telling «No module named django».
│ │ │ │ │ This tutorial is written for Django 5.1, which supports Python 3.10 and later.
│ │ │ │ │ If the Django version doesn’t match, you can refer to the tutorial for your
│ │ │ │ │ version of Django by using the version switcher at the bottom right corner of
│ │ │ │ │ this page, or update Django to the newest version. If you’re using an older
│ │ │ │ │ version of Python, check _W_h_a_t_ _P_y_t_h_o_n_ _v_e_r_s_i_o_n_ _c_a_n_ _I_ _u_s_e_ _w_i_t_h_ _D_j_a_n_g_o_? to find a
│ │ │ │ │ compatible version of Django.
│ │ │ │ │ See _H_o_w_ _t_o_ _i_n_s_t_a_l_l_ _D_j_a_n_g_o for advice on how to remove older versions of Django
│ │ │ │ │ @@ -36,15 +36,15 @@
│ │ │ │ │ From the command line, cd into a directory where you’d like to store your code,
│ │ │ │ │ then run the following command:
│ │ │ │ │ #/ o
│ │ │ │ │ $ django-admin startproject mysite
│ │ │ │ │ ...\> django-admin startproject mysite
│ │ │ │ │ This will create a mysite directory in your current directory. If it didn’t
│ │ │ │ │ work, see _P_r_o_b_l_e_m_s_ _r_u_n_n_i_n_g_ _d_j_a_n_g_o_-_a_d_m_i_n.
│ │ │ │ │ -Note
│ │ │ │ │ +Nota
│ │ │ │ │ You’ll need to avoid naming projects after built-in Python or Django
│ │ │ │ │ components. In particular, this means you should avoid using names like django
│ │ │ │ │ (which will conflict with Django itself) or test (which conflicts with a built-
│ │ │ │ │ in Python package).
│ │ │ │ │ Let’s look at what _s_t_a_r_t_p_r_o_j_e_c_t created:
│ │ │ │ │ mysite/
│ │ │ │ │ manage.py
│ │ │ │ │ @@ -64,16 +64,16 @@
│ │ │ │ │ project. Its name is the Python package name you’ll need to use to import
│ │ │ │ │ anything inside it (e.g. mysite.urls).
│ │ │ │ │ * mysite/__init__.py: An empty file that tells Python that this directory
│ │ │ │ │ should be considered a Python package. If you’re a Python beginner, read
│ │ │ │ │ _m_o_r_e_ _a_b_o_u_t_ _p_a_c_k_a_g_e_s in the official Python docs.
│ │ │ │ │ * mysite/settings.py: Settings/configuration for this Django project.
│ │ │ │ │ _D_j_a_n_g_o_ _s_e_t_t_i_n_g_s will tell you all about how settings work.
│ │ │ │ │ - * mysite/urls.py: The URL declarations for this Django project; a “table of
│ │ │ │ │ - contents” of your Django-powered site. You can read more about URLs in
│ │ │ │ │ + * mysite/urls.py: The URL declarations for this Django project; a «table of
│ │ │ │ │ + contents» of your Django-powered site. You can read more about URLs in
│ │ │ │ │ _U_R_L_ _d_i_s_p_a_t_c_h_e_r.
│ │ │ │ │ * mysite/asgi.py: An entry-point for ASGI-compatible web servers to serve
│ │ │ │ │ your project. See _H_o_w_ _t_o_ _d_e_p_l_o_y_ _w_i_t_h_ _A_S_G_I for more details.
│ │ │ │ │ * mysite/wsgi.py: An entry-point for WSGI-compatible web servers to serve
│ │ │ │ │ your project. See _H_o_w_ _t_o_ _d_e_p_l_o_y_ _w_i_t_h_ _W_S_G_I for more details.
│ │ │ │ │ ********** TThhee ddeevveellooppmmeenntt sseerrvveerr_?¶ **********
│ │ │ │ │ Let’s verify your Django project works. Change into the outer mysite directory,
│ │ │ │ │ @@ -86,23 +86,23 @@
│ │ │ │ │
│ │ │ │ │ System check identified no issues (0 silenced).
│ │ │ │ │
│ │ │ │ │ You have unapplied migrations; your app may not work properly until they are
│ │ │ │ │ applied.
│ │ │ │ │ Run 'python manage.py migrate' to apply them.
│ │ │ │ │
│ │ │ │ │ -June 26, 2024 - 15:50:53
│ │ │ │ │ +giugno 26, 2024 - 15:50:53
│ │ │ │ │ Django version 5.1, using settings 'mysite.settings'
│ │ │ │ │ Starting development server at _h_t_t_p_:_/_/_1_2_7_._0_._0_._1_:_8_0_0_0_/
│ │ │ │ │ Quit the server with CONTROL-C.
│ │ │ │ │ -Note
│ │ │ │ │ +Nota
│ │ │ │ │ Ignore the warning about unapplied database migrations for now; we’ll deal with
│ │ │ │ │ the database shortly.
│ │ │ │ │ Now that the server’s running, visit _h_t_t_p_:_/_/_1_2_7_._0_._0_._1_:_8_0_0_0_/ with your web
│ │ │ │ │ -browser. You’ll see a “Congratulations!” page, with a rocket taking off. It
│ │ │ │ │ +browser. You’ll see a «Congratulations!» page, with a rocket taking off. It
│ │ │ │ │ worked!
│ │ │ │ │ You’ve started the Django development server, a lightweight web server written
│ │ │ │ │ purely in Python. We’ve included this with Django so you can develop things
│ │ │ │ │ rapidly, without having to deal with configuring a production server – such as
│ │ │ │ │ Apache – until you’re ready for production.
│ │ │ │ │ Now’s a good time to note: ddoonn?’tt use this server in anything resembling a
│ │ │ │ │ production environment. It’s intended only for use while developing. (We’re in
│ │ │ │ │ @@ -110,15 +110,15 @@
│ │ │ │ │ (To serve the site on a different port, see the _r_u_n_s_e_r_v_e_r reference.)
│ │ │ │ │ Automatic reloading of _r_u_n_s_e_r_v_e_r
│ │ │ │ │ The development server automatically reloads Python code for each request as
│ │ │ │ │ needed. You don’t need to restart the server for code changes to take effect.
│ │ │ │ │ However, some actions like adding files don’t trigger a restart, so you’ll have
│ │ │ │ │ to restart the server in these cases.
│ │ │ │ │ ********** CCrreeaattiinngg tthhee PPoollllss aapppp_?¶ **********
│ │ │ │ │ -Now that your environment – a “project” – is set up, you’re set to start doing
│ │ │ │ │ +Now that your environment – a «project» – is set up, you’re set to start doing
│ │ │ │ │ work.
│ │ │ │ │ Each application you write in Django consists of a Python package that follows
│ │ │ │ │ a certain convention. Django comes with a utility that automatically generates
│ │ │ │ │ the basic directory structure of an app, so you can focus on writing code
│ │ │ │ │ rather than creating directories.
│ │ │ │ │ Projects vs. apps
│ │ │ │ │ What’s the difference between a project and an app? An app is a web application
│ │ │ │ │ @@ -189,27 +189,27 @@
│ │ │ │ │ path("admin/", admin.site.urls),
│ │ │ │ │ ]
│ │ │ │ │ The _i_n_c_l_u_d_e_(_) function allows referencing other URLconfs. Whenever Django
│ │ │ │ │ encounters _i_n_c_l_u_d_e_(_), it chops off whatever part of the URL matched up to that
│ │ │ │ │ point and sends the remaining string to the included URLconf for further
│ │ │ │ │ processing.
│ │ │ │ │ The idea behind _i_n_c_l_u_d_e_(_) is to make it easy to plug-and-play URLs. Since polls
│ │ │ │ │ -are in their own URLconf (polls/urls.py), they can be placed under “/polls/”,
│ │ │ │ │ -or under “/fun_polls/”, or under “/content/polls/”, or any other path root, and
│ │ │ │ │ +are in their own URLconf (polls/urls.py), they can be placed under «/polls/»,
│ │ │ │ │ +or under «/fun_polls/», or under «/content/polls/», or any other path root, and
│ │ │ │ │ the app will still work.
│ │ │ │ │ When to use _i_n_c_l_u_d_e_(_)
│ │ │ │ │ You should always use include() when you include other URL patterns.
│ │ │ │ │ admin.site.urls is the only exception to this.
│ │ │ │ │ You have now wired an index view into the URLconf. Verify it’s working with the
│ │ │ │ │ following command:
│ │ │ │ │ #/ o
│ │ │ │ │ $ python manage.py runserver
│ │ │ │ │ ...\> py manage.py runserver
│ │ │ │ │ Go to _h_t_t_p_:_/_/_l_o_c_a_l_h_o_s_t_:_8_0_0_0_/_p_o_l_l_s_/ in your browser, and you should see the text
│ │ │ │ │ -“HHeelllloo,, wwoorrlldd.. YYoouu?’rree aatt tthhee ppoollllss iinnddeexx..”, which you defined in the index
│ │ │ │ │ +«HHeelllloo,, wwoorrlldd.. YYoouu?’rree aatt tthhee ppoollllss iinnddeexx..», which you defined in the index
│ │ │ │ │ view.
│ │ │ │ │ Page not found?
│ │ │ │ │ If you get an error page here, check that you’re going to _h_t_t_p_:_/_/_l_o_c_a_l_h_o_s_t_:
│ │ │ │ │ _8_0_0_0_/_p_o_l_l_s_/ and not _h_t_t_p_:_/_/_l_o_c_a_l_h_o_s_t_:_8_0_0_0_/.
│ │ │ │ │ The _p_a_t_h_(_) function is passed four arguments, two required: route and view, and
│ │ │ │ │ two optional: kwargs, and name. At this point, it’s worth reviewing what these
│ │ │ │ │ arguments are for.
│ │ │ │ │ @@ -220,15 +220,15 @@
│ │ │ │ │ matches.
│ │ │ │ │ Patterns don’t search GET and POST parameters, or the domain name. For example,
│ │ │ │ │ in a request to https://www.example.com/myapp/, the URLconf will look for
│ │ │ │ │ myapp/. In a request to https://www.example.com/myapp/?page=3, the URLconf will
│ │ │ │ │ also look for myapp/.
│ │ │ │ │ ******** _pp_aa_tt_hh_((_)) aarrgguummeenntt:: vviieeww_?¶ ********
│ │ │ │ │ When Django finds a matching pattern, it calls the specified view function with
│ │ │ │ │ -an _H_t_t_p_R_e_q_u_e_s_t object as the first argument and any “captured” values from the
│ │ │ │ │ +an _H_t_t_p_R_e_q_u_e_s_t object as the first argument and any «captured» values from the
│ │ │ │ │ route as keyword arguments. We’ll give an example of this in a bit.
│ │ │ │ │ ******** _pp_aa_tt_hh_((_)) aarrgguummeenntt:: kkwwaarrggss_?¶ ********
│ │ │ │ │ Arbitrary keyword arguments can be passed in a dictionary to the target view.
│ │ │ │ │ We aren’t going to use this feature of Django in the tutorial.
│ │ │ │ │ ******** _pp_aa_tt_hh_((_)) aarrgguummeenntt:: nnaammee_?¶ ********
│ │ │ │ │ Naming your URL lets you refer to it unambiguously from elsewhere in Django,
│ │ │ │ │ especially from within templates. This powerful feature allows you to make
│ │ │ │ │ @@ -242,16 +242,16 @@
│ │ │ │ │ o _T_h_e_ _d_e_v_e_l_o_p_m_e_n_t_ _s_e_r_v_e_r
│ │ │ │ │ o _C_r_e_a_t_i_n_g_ _t_h_e_ _P_o_l_l_s_ _a_p_p
│ │ │ │ │ o _W_r_i_t_e_ _y_o_u_r_ _f_i_r_s_t_ _v_i_e_w
│ │ │ │ │ # _p_a_t_h_(_)_ _a_r_g_u_m_e_n_t_:_ _r_o_u_t_e
│ │ │ │ │ # _p_a_t_h_(_)_ _a_r_g_u_m_e_n_t_:_ _v_i_e_w
│ │ │ │ │ # _p_a_t_h_(_)_ _a_r_g_u_m_e_n_t_:_ _k_w_a_r_g_s
│ │ │ │ │ # _p_a_t_h_(_)_ _a_r_g_u_m_e_n_t_:_ _n_a_m_e
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _Q_u_i_c_k_ _i_n_s_t_a_l_l_ _g_u_i_d_e
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _D_j_a_n_g_o_ _a_p_p_,_ _p_a_r_t_ _2
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/intro/tutorial02.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Writing your first Django app, part 2 — Django 5.1b1 documentation
│ │ │ │ + Writing your first Django app, part 2 — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -66,15 +67,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
If you are not using SQLite as your database, additional settings such as
│ │ │ │ USER, PASSWORD, and HOST must be added.
│ │ │ │ For more details, see the reference documentation for DATABASES.
│ │ │ │
│ │ │ │
For databases other than SQLite
│ │ │ │
If you’re using a database besides SQLite, make sure you’ve created a
│ │ │ │ -database by this point. Do that with “CREATEDATABASEdatabase_name;”
│ │ │ │ +database by this point. Do that with «CREATEDATABASEdatabase_name;»
│ │ │ │ within your database’s interactive prompt.
│ │ │ │
Also make sure that the database user provided in mysite/settings.py
│ │ │ │ -has “create database” privileges. This allows automatic creation of a
│ │ │ │ +has «create database» privileges. This allows automatic creation of a
│ │ │ │ test database which will be needed in a later
│ │ │ │ tutorial.
│ │ │ │
If you’re using SQLite, you don’t need to create anything beforehand - the
│ │ │ │ database file will be created automatically when it is needed.
│ │ │ │
│ │ │ │
While you’re editing mysite/settings.py, set TIME_ZONE to
│ │ │ │ your time zone.
│ │ │ │ @@ -270,15 +271,15 @@
│ │ │ │
│ │ │ │
Create a database schema (CREATETABLE statements) for this app.
│ │ │ │
Create a Python database-access API for accessing Question and Choice objects.
│ │ │ │
│ │ │ │
But first we need to tell our project that the polls app is installed.
│ │ │ │
│ │ │ │
Philosophy
│ │ │ │ -
Django apps are “pluggable”: You can use an app in multiple projects, and
│ │ │ │ +
Django apps are «pluggable»: You can use an app in multiple projects, and
│ │ │ │ you can distribute apps, because they don’t have to be tied to a given
│ │ │ │ Django installation.
│ │ │ │
│ │ │ │
To include the app in our project, we need to add a reference to its
│ │ │ │ configuration class in the INSTALLED_APPS setting. The
│ │ │ │ PollsConfig class is in the polls/apps.py file, so its dotted path
│ │ │ │ is 'polls.apps.PollsConfig'. Edit the mysite/settings.py file and
│ │ │ │ @@ -471,15 +472,15 @@
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
...\> py manage.py shell
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ -
We’re using this instead of simply typing “python”, because manage.py
│ │ │ │ +
We’re using this instead of simply typing «python», because manage.py
│ │ │ │ sets the DJANGO_SETTINGS_MODULE environment variable, which gives
│ │ │ │ Django the Python import path to your mysite/settings.py file.
│ │ │ │
Once you’re in the shell, explore the database API:
│ │ │ │
>>> frompolls.modelsimportChoice,Question# Import the model classes we just wrote.
│ │ │ │
│ │ │ │ # No questions are in the system yet.
│ │ │ │ >>> Question.objects.all()
│ │ │ │ @@ -535,15 +536,15 @@
│ │ │ │ def__str__(self):
│ │ │ │ returnself.choice_text
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
It’s important to add __str__() methods to your
│ │ │ │ models, not only for your own convenience when dealing with the interactive
│ │ │ │ -prompt, but also because objects’ representations are used throughout Django’s
│ │ │ │ +prompt, but also because objects” representations are used throughout Django’s
│ │ │ │ automatically-generated admin.
Generating admin sites for your staff or clients to add, change, and delete
│ │ │ │ content is tedious work that doesn’t require much creativity. For that
│ │ │ │ reason, Django entirely automates creation of admin interfaces for models.
│ │ │ │
Django was written in a newsroom environment, with a very clear separation
│ │ │ │ -between “content publishers” and the “public” site. Site managers use the
│ │ │ │ +between «content publishers» and the «public» site. Site managers use the
│ │ │ │ system to add news stories, events, sports scores, etc., and that content is
│ │ │ │ displayed on the public site. Django solves the problem of creating a
│ │ │ │ unified interface for site administrators to edit content.
│ │ │ │
The admin isn’t intended to be used by site visitors. It’s for site
│ │ │ │ managers.
│ │ │ │
│ │ │ │
│ │ │ │ @@ -711,15 +712,15 @@
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
...\> py manage.py runserver
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ -
Now, open a web browser and go to “/admin/” on your local domain – e.g.,
│ │ │ │ +
Now, open a web browser and go to «/admin/» on your local domain – e.g.,
│ │ │ │ http://127.0.0.1:8000/admin/. You should see the admin’s login screen:
│ │ │ │
│ │ │ │
Since translation is turned on by default, if
│ │ │ │ you set LANGUAGE_CODE, the login screen will be displayed in the
│ │ │ │ given language (if Django has appropriate translations).
Now that we’ve registered Question, Django knows that it should be displayed on
│ │ │ │ the admin index page:
│ │ │ │
│ │ │ │ -
Click “Questions”. Now you’re at the “change list” page for questions. This page
│ │ │ │ +
Click «Questions». Now you’re at the «change list» page for questions. This page
│ │ │ │ displays all the questions in the database and lets you choose one to change it.
│ │ │ │ -There’s the “What’s up?” question we created earlier:
│ │ │ │ +There’s the «What’s up?» question we created earlier:
│ │ │ │
│ │ │ │ -
Click the “What’s up?” question to edit it:
│ │ │ │ +
Click the «What’s up?» question to edit it:
│ │ │ │
│ │ │ │
Things to note here:
│ │ │ │
│ │ │ │
The form is automatically generated from the Question model.
│ │ │ │
The different model field types (DateTimeField,
│ │ │ │ CharField) correspond to the appropriate HTML
│ │ │ │ input widget. Each type of field knows how to display itself in the Django
│ │ │ │ admin.
│ │ │ │
Each DateTimeField gets free JavaScript
│ │ │ │ -shortcuts. Dates get a “Today” shortcut and calendar popup, and times get
│ │ │ │ -a “Now” shortcut and a convenient popup that lists commonly entered times.
│ │ │ │ +shortcuts. Dates get a «Today» shortcut and calendar popup, and times get
│ │ │ │ +a «Now» shortcut and a convenient popup that lists commonly entered times.
│ │ │ │
│ │ │ │
The bottom part of the page gives you a couple of options:
│ │ │ │
│ │ │ │
Save – Saves changes and returns to the change-list page for this type of
│ │ │ │ object.
│ │ │ │
Save and continue editing – Saves changes and reloads the admin page for
│ │ │ │ this object.
│ │ │ │
Save and add another – Saves changes and loads a new, blank form for this
│ │ │ │ type of object.
│ │ │ │
Delete – Displays a delete confirmation page.
│ │ │ │
│ │ │ │ -
If the value of “Date published” doesn’t match the time when you created the
│ │ │ │ +
If the value of «Date published» doesn’t match the time when you created the
│ │ │ │ question in Tutorial 1, it probably
│ │ │ │ means you forgot to set the correct value for the TIME_ZONE setting.
│ │ │ │ Change it, reload the page and check that the correct value appears.
│ │ │ │ -
Change the “Date published” by clicking the “Today” and “Now” shortcuts. Then
│ │ │ │ -click “Save and continue editing.” Then click “History” in the upper right.
│ │ │ │ +
Change the «Date published» by clicking the «Today» and «Now» shortcuts. Then
│ │ │ │ +click «Save and continue editing.» Then click «History» in the upper right.
│ │ │ │ You’ll see a page listing all changes made to this object via the Django admin,
│ │ │ │ with the timestamp and username of the person who made the change:
│ │ │ │
│ │ │ │
When you’re comfortable with the models API and have familiarized yourself with
│ │ │ │ the admin site, read part 3 of this tutorial to learn
│ │ │ │ about how to add more views to our polls app.
│ │ │ │ + title="capitolo successivo">Writing your first Django app, part 3
│ │ │ │
│ │ │ │
│ │ │ │ -
Quick search
│ │ │ │ +
Ricerca veloce
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Last update:
│ │ │ │ -
Jun 26, 2024
│ │ │ │ +
giu 26, 2024
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ WWrriittiinngg yyoouurr ffiirrsstt DDjjaannggoo aapppp,, ppaarrtt 22_?¶ ************
│ │ │ │ │ This tutorial begins where _T_u_t_o_r_i_a_l_ _1 left off. We’ll set up the database,
│ │ │ │ │ create your first model, and get a quick introduction to Django’s
│ │ │ │ │ automatically-generated admin site.
│ │ │ │ │ Where to get help:
│ │ │ │ │ @@ -28,18 +28,18 @@
│ │ │ │ │ absolute path, including filename, of that file. The default value,
│ │ │ │ │ BASE_DIR / 'db.sqlite3', will store the file in your project directory.
│ │ │ │ │ If you are not using SQLite as your database, additional settings such as _U_S_E_R,
│ │ │ │ │ _P_A_S_S_W_O_R_D, and _H_O_S_T must be added. For more details, see the reference
│ │ │ │ │ documentation for _D_A_T_A_B_A_S_E_S.
│ │ │ │ │ For databases other than SQLite
│ │ │ │ │ If you’re using a database besides SQLite, make sure you’ve created a database
│ │ │ │ │ -by this point. Do that with “CREATE DATABASE database_name;” within your
│ │ │ │ │ +by this point. Do that with «CREATE DATABASE database_name;» within your
│ │ │ │ │ database’s interactive prompt.
│ │ │ │ │ Also make sure that the database user provided in mysite/settings.py has
│ │ │ │ │ -“create database” privileges. This allows automatic creation of a _t_e_s_t_ _d_a_t_a_b_a_s_e
│ │ │ │ │ +«create database» privileges. This allows automatic creation of a _t_e_s_t_ _d_a_t_a_b_a_s_e
│ │ │ │ │ which will be needed in a later tutorial.
│ │ │ │ │ If you’re using SQLite, you don’t need to create anything beforehand - the
│ │ │ │ │ database file will be created automatically when it is needed.
│ │ │ │ │ While you’re editing mysite/settings.py, set _T_I_M_E___Z_O_N_E to your time zone.
│ │ │ │ │ Also, note the _I_N_S_T_A_L_L_E_D___A_P_P_S setting at the top of the file. That holds the
│ │ │ │ │ names of all Django applications that are activated in this Django instance.
│ │ │ │ │ Apps can be used in multiple projects, and you can package and distribute them
│ │ │ │ │ @@ -130,15 +130,15 @@
│ │ │ │ │ That small bit of model code gives Django a lot of information. With it, Django
│ │ │ │ │ is able to:
│ │ │ │ │ * Create a database schema (CREATE TABLE statements) for this app.
│ │ │ │ │ * Create a Python database-access API for accessing Question and Choice
│ │ │ │ │ objects.
│ │ │ │ │ But first we need to tell our project that the polls app is installed.
│ │ │ │ │ Philosophy
│ │ │ │ │ -Django apps are “pluggable”: You can use an app in multiple projects, and you
│ │ │ │ │ +Django apps are «pluggable»: You can use an app in multiple projects, and you
│ │ │ │ │ can distribute apps, because they don’t have to be tied to a given Django
│ │ │ │ │ installation.
│ │ │ │ │ To include the app in our project, we need to add a reference to its
│ │ │ │ │ configuration class in the _I_N_S_T_A_L_L_E_D___A_P_P_S setting. The PollsConfig class is in
│ │ │ │ │ the polls/apps.py file, so its dotted path is 'polls.apps.PollsConfig'. Edit
│ │ │ │ │ the mysite/settings.py file and add that dotted path to the _I_N_S_T_A_L_L_E_D___A_P_P_S
│ │ │ │ │ setting. It’ll look like this:
│ │ │ │ │ @@ -268,15 +268,15 @@
│ │ │ │ │ utility can do.
│ │ │ │ │ ********** PPllaayyiinngg wwiitthh tthhee AAPPII_?¶ **********
│ │ │ │ │ Now, let’s hop into the interactive Python shell and play around with the free
│ │ │ │ │ API Django gives you. To invoke the Python shell, use this command:
│ │ │ │ │ #/ o
│ │ │ │ │ $ python manage.py shell
│ │ │ │ │ ...\> py manage.py shell
│ │ │ │ │ -We’re using this instead of simply typing “python”, because manage.py sets the
│ │ │ │ │ +We’re using this instead of simply typing «python», because manage.py sets the
│ │ │ │ │ _D_J_A_N_G_O___S_E_T_T_I_N_G_S___M_O_D_U_L_E environment variable, which gives Django the Python
│ │ │ │ │ import path to your mysite/settings.py file.
│ │ │ │ │ Once you’re in the shell, explore the _d_a_t_a_b_a_s_e_ _A_P_I:
│ │ │ │ │ >>> from polls.models import Choice, Question # Import the model classes we
│ │ │ │ │ just wrote.
│ │ │ │ │
│ │ │ │ │ # No questions are in the system yet.
│ │ │ │ │ @@ -324,15 +324,15 @@
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ class Choice(models.Model):
│ │ │ │ │ # ...
│ │ │ │ │ def __str__(self):
│ │ │ │ │ return self.choice_text
│ │ │ │ │ It’s important to add _____s_t_r_____(_) methods to your models, not only for your own
│ │ │ │ │ -convenience when dealing with the interactive prompt, but also because objects’
│ │ │ │ │ +convenience when dealing with the interactive prompt, but also because objects”
│ │ │ │ │ representations are used throughout Django’s automatically-generated admin.
│ │ │ │ │ Let’s also add a custom method to this model:
│ │ │ │ │ polls/models.py_¶
│ │ │ │ │ import datetime
│ │ │ │ │
│ │ │ │ │ from django.db import models
│ │ │ │ │ from django.utils import timezone
│ │ │ │ │ @@ -431,15 +431,15 @@
│ │ │ │ │ _r_e_f_e_r_e_n_c_e.
│ │ │ │ │ ********** IInnttrroodduucciinngg tthhee DDjjaannggoo AAddmmiinn_?¶ **********
│ │ │ │ │ Philosophy
│ │ │ │ │ Generating admin sites for your staff or clients to add, change, and delete
│ │ │ │ │ content is tedious work that doesn’t require much creativity. For that reason,
│ │ │ │ │ Django entirely automates creation of admin interfaces for models.
│ │ │ │ │ Django was written in a newsroom environment, with a very clear separation
│ │ │ │ │ -between “content publishers” and the “public” site. Site managers use the
│ │ │ │ │ +between «content publishers» and the «public» site. Site managers use the
│ │ │ │ │ system to add news stories, events, sports scores, etc., and that content is
│ │ │ │ │ displayed on the public site. Django solves the problem of creating a unified
│ │ │ │ │ interface for site administrators to edit content.
│ │ │ │ │ The admin isn’t intended to be used by site visitors. It’s for site managers.
│ │ │ │ │ ******** CCrreeaattiinngg aann aaddmmiinn uusseerr_?¶ ********
│ │ │ │ │ First we’ll need to create a user who can login to the admin site. Run the
│ │ │ │ │ following command:
│ │ │ │ │ @@ -458,15 +458,15 @@
│ │ │ │ │ ******** SSttaarrtt tthhee ddeevveellooppmmeenntt sseerrvveerr_?¶ ********
│ │ │ │ │ The Django admin site is activated by default. Let’s start the development
│ │ │ │ │ server and explore it.
│ │ │ │ │ If the server is not running start it like so:
│ │ │ │ │ #/ o
│ │ │ │ │ $ python manage.py runserver
│ │ │ │ │ ...\> py manage.py runserver
│ │ │ │ │ -Now, open a web browser and go to “/admin/” on your local domain – e.g., _h_t_t_p_:_/
│ │ │ │ │ +Now, open a web browser and go to «/admin/» on your local domain – e.g., _h_t_t_p_:_/
│ │ │ │ │ _/_1_2_7_._0_._0_._1_:_8_0_0_0_/_a_d_m_i_n_/. You should see the admin’s login screen:
│ │ │ │ │ [Django admin login screen]
│ │ │ │ │ Since _t_r_a_n_s_l_a_t_i_o_n is turned on by default, if you set _L_A_N_G_U_A_G_E___C_O_D_E, the login
│ │ │ │ │ screen will be displayed in the given language (if Django has appropriate
│ │ │ │ │ translations).
│ │ │ │ │ ******** EEnntteerr tthhee aaddmmiinn ssiittee_?¶ ********
│ │ │ │ │ Now, try logging in with the superuser account you created in the previous
│ │ │ │ │ @@ -486,42 +486,42 @@
│ │ │ │ │ from .models import Question
│ │ │ │ │
│ │ │ │ │ admin.site.register(Question)
│ │ │ │ │ ******** EExxpplloorree tthhee ffrreeee aaddmmiinn ffuunnccttiioonnaalliittyy_?¶ ********
│ │ │ │ │ Now that we’ve registered Question, Django knows that it should be displayed on
│ │ │ │ │ the admin index page:
│ │ │ │ │ [Django admin index page, now with polls displayed]
│ │ │ │ │ -Click “Questions”. Now you’re at the “change list” page for questions. This
│ │ │ │ │ +Click «Questions». Now you’re at the «change list» page for questions. This
│ │ │ │ │ page displays all the questions in the database and lets you choose one to
│ │ │ │ │ -change it. There’s the “What’s up?” question we created earlier:
│ │ │ │ │ +change it. There’s the «What’s up?» question we created earlier:
│ │ │ │ │ [Polls change list page]
│ │ │ │ │ -Click the “What’s up?” question to edit it:
│ │ │ │ │ +Click the «What’s up?» question to edit it:
│ │ │ │ │ [Editing form for question object]
│ │ │ │ │ Things to note here:
│ │ │ │ │ * The form is automatically generated from the Question model.
│ │ │ │ │ * The different model field types (_D_a_t_e_T_i_m_e_F_i_e_l_d, _C_h_a_r_F_i_e_l_d) correspond to
│ │ │ │ │ the appropriate HTML input widget. Each type of field knows how to
│ │ │ │ │ display itself in the Django admin.
│ │ │ │ │ - * Each _D_a_t_e_T_i_m_e_F_i_e_l_d gets free JavaScript shortcuts. Dates get a “Today”
│ │ │ │ │ - shortcut and calendar popup, and times get a “Now” shortcut and a
│ │ │ │ │ + * Each _D_a_t_e_T_i_m_e_F_i_e_l_d gets free JavaScript shortcuts. Dates get a «Today»
│ │ │ │ │ + shortcut and calendar popup, and times get a «Now» shortcut and a
│ │ │ │ │ convenient popup that lists commonly entered times.
│ │ │ │ │ The bottom part of the page gives you a couple of options:
│ │ │ │ │ * Save – Saves changes and returns to the change-list page for this type of
│ │ │ │ │ object.
│ │ │ │ │ * Save and continue editing – Saves changes and reloads the admin page for
│ │ │ │ │ this object.
│ │ │ │ │ * Save and add another – Saves changes and loads a new, blank form for this
│ │ │ │ │ type of object.
│ │ │ │ │ * Delete – Displays a delete confirmation page.
│ │ │ │ │ -If the value of “Date published” doesn’t match the time when you created the
│ │ │ │ │ +If the value of «Date published» doesn’t match the time when you created the
│ │ │ │ │ question in _T_u_t_o_r_i_a_l_ _1, it probably means you forgot to set the correct value
│ │ │ │ │ for the _T_I_M_E___Z_O_N_E setting. Change it, reload the page and check that the
│ │ │ │ │ correct value appears.
│ │ │ │ │ -Change the “Date published” by clicking the “Today” and “Now” shortcuts. Then
│ │ │ │ │ -click “Save and continue editing.” Then click “History” in the upper right.
│ │ │ │ │ +Change the «Date published» by clicking the «Today» and «Now» shortcuts. Then
│ │ │ │ │ +click «Save and continue editing.» Then click «History» in the upper right.
│ │ │ │ │ You’ll see a page listing all changes made to this object via the Django admin,
│ │ │ │ │ with the timestamp and username of the person who made the change:
│ │ │ │ │ [History page for question object]
│ │ │ │ │ When you’re comfortable with the models API and have familiarized yourself with
│ │ │ │ │ the admin site, read _p_a_r_t_ _3_ _o_f_ _t_h_i_s_ _t_u_t_o_r_i_a_l to learn about how to add more
│ │ │ │ │ views to our polls app.
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ @@ -532,16 +532,16 @@
│ │ │ │ │ o _P_l_a_y_i_n_g_ _w_i_t_h_ _t_h_e_ _A_P_I
│ │ │ │ │ o _I_n_t_r_o_d_u_c_i_n_g_ _t_h_e_ _D_j_a_n_g_o_ _A_d_m_i_n
│ │ │ │ │ # _C_r_e_a_t_i_n_g_ _a_n_ _a_d_m_i_n_ _u_s_e_r
│ │ │ │ │ # _S_t_a_r_t_ _t_h_e_ _d_e_v_e_l_o_p_m_e_n_t_ _s_e_r_v_e_r
│ │ │ │ │ # _E_n_t_e_r_ _t_h_e_ _a_d_m_i_n_ _s_i_t_e
│ │ │ │ │ # _M_a_k_e_ _t_h_e_ _p_o_l_l_ _a_p_p_ _m_o_d_i_f_i_a_b_l_e_ _i_n_ _t_h_e_ _a_d_m_i_n
│ │ │ │ │ # _E_x_p_l_o_r_e_ _t_h_e_ _f_r_e_e_ _a_d_m_i_n_ _f_u_n_c_t_i_o_n_a_l_i_t_y
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _D_j_a_n_g_o_ _a_p_p_,_ _p_a_r_t_ _1
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _D_j_a_n_g_o_ _a_p_p_,_ _p_a_r_t_ _3
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/intro/tutorial03.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Writing your first Django app, part 3 — Django 5.1b1 documentation
│ │ │ │ + Writing your first Django app, part 3 — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,15 +54,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
This tutorial begins where Tutorial 2 left off. We’re
│ │ │ │ continuing the web-poll application and will focus on creating the public
│ │ │ │ -interface – “views.”
│ │ │ │ +interface – «views.»
│ │ │ │
│ │ │ │
Where to get help:
│ │ │ │
If you’re having trouble going through this tutorial, please head over to
│ │ │ │ the Getting Help section of the FAQ.
A view is a “type” of web page in your Django application that generally serves
│ │ │ │ +
A view is a «type» of web page in your Django application that generally serves
│ │ │ │ a specific function and has a specific template. For example, in a blog
│ │ │ │ application, you might have the following views:
│ │ │ │
│ │ │ │
Blog homepage – displays the latest few entries.
│ │ │ │ -
Entry “detail” page – permalink page for a single entry.
│ │ │ │ +
Entry «detail» page – permalink page for a single entry.
│ │ │ │
Year-based archive page – displays all months with entries in the
│ │ │ │ given year.
│ │ │ │
Month-based archive page – displays all days with entries in the
│ │ │ │ given month.
│ │ │ │
Day-based archive page – displays all entries in the given day.
│ │ │ │
Comment action – handles posting comments to a given entry.
│ │ │ │
│ │ │ │
In our poll application, we’ll have the following four views:
│ │ │ │
│ │ │ │ -
Question “index” page – displays the latest few questions.
│ │ │ │ -
Question “detail” page – displays a question text, with no results but
│ │ │ │ +
Question «index» page – displays the latest few questions.
│ │ │ │ +
Question «detail» page – displays a question text, with no results but
│ │ │ │ with a form to vote.
│ │ │ │ -
Question “results” page – displays results for a particular question.
│ │ │ │ +
Question «results» page – displays results for a particular question.
│ │ │ │
Vote action – handles voting for a particular choice in a particular
│ │ │ │ question.
│ │ │ │
│ │ │ │
In Django, web pages and other content are delivered by views. Each view is
│ │ │ │ represented by a Python function (or method, in the case of class-based views).
│ │ │ │ Django will choose a view by examining the URL that’s requested (to be precise,
│ │ │ │ the part of the URL after the domain name).
│ │ │ │
Now in your time on the web you may have come across such beauties as
│ │ │ │ ME2/Sites/dirmod.htm?sid=&type=gen&mod=Core+Pages&gid=A6CD4967199A42D9B65B1B.
│ │ │ │ You will be pleased to know that Django allows us much more elegant
│ │ │ │ URL patterns than that.
│ │ │ │
A URL pattern is the general form of a URL - for example:
│ │ │ │ /newsarchive/<year>/<month>/.
│ │ │ │ -
To get from a URL to a view, Django uses what are known as ‘URLconfs’. A
│ │ │ │ +
To get from a URL to a view, Django uses what are known as “URLconfs”. A
│ │ │ │ URLconf maps URL patterns to views.
│ │ │ │
This tutorial provides basic instruction in the use of URLconfs, and you can
│ │ │ │ refer to URL dispatcher for more information.
Now let’s add a few more views to polls/views.py. These views are
│ │ │ │ @@ -163,31 +164,31 @@
│ │ │ │ path("<int:question_id>/results/",views.results,name="results"),
│ │ │ │ # ex: /polls/5/vote/
│ │ │ │ path("<int:question_id>/vote/",views.vote,name="vote"),
│ │ │ │ ]
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ -
Take a look in your browser, at “/polls/34/”. It’ll run the detail()
│ │ │ │ +
Take a look in your browser, at «/polls/34/». It’ll run the detail()
│ │ │ │ function and display whatever ID you provide in the URL. Try
│ │ │ │ -“/polls/34/results/” and “/polls/34/vote/” too – these will display the
│ │ │ │ +«/polls/34/results/» and «/polls/34/vote/» too – these will display the
│ │ │ │ placeholder results and voting pages.
│ │ │ │ -
When somebody requests a page from your website – say, “/polls/34/”, Django
│ │ │ │ +
When somebody requests a page from your website – say, «/polls/34/», Django
│ │ │ │ will load the mysite.urls Python module because it’s pointed to by the
│ │ │ │ ROOT_URLCONF setting. It finds the variable named urlpatterns
│ │ │ │ and traverses the patterns in order. After finding the match at 'polls/',
│ │ │ │ it strips off the matching text ("polls/") and sends the remaining text –
│ │ │ │ -"34/" – to the ‘polls.urls’ URLconf for further processing. There it
│ │ │ │ +"34/" – to the “polls.urls” URLconf for further processing. There it
│ │ │ │ matches '<int:question_id>/', resulting in a call to the detail() view
│ │ │ │ like so:
The question_id=34 part comes from <int:question_id>. Using angle
│ │ │ │ -brackets “captures” part of the URL and sends it as a keyword argument to the
│ │ │ │ +brackets «captures» part of the URL and sends it as a keyword argument to the
│ │ │ │ view function. The question_id part of the string defines the name that
│ │ │ │ will be used to identify the matched pattern, and the int part is a
│ │ │ │ converter that determines what patterns should match this part of the URL path.
│ │ │ │ The colon (:) separates the converter and pattern name.
│ │ │ │ @@ -226,15 +227,15 @@
│ │ │ │ So let’s use Django’s template system to separate the design from Python by
│ │ │ │ creating a template that the view can use.
│ │ │ │
First, create a directory called templates in your polls directory.
│ │ │ │ Django will look for templates in there.
│ │ │ │
Your project’s TEMPLATES setting describes how Django will load and
│ │ │ │ render templates. The default settings file configures a DjangoTemplates
│ │ │ │ backend whose APP_DIRS option is set to
│ │ │ │ -True. By convention DjangoTemplates looks for a “templates”
│ │ │ │ +True. By convention DjangoTemplates looks for a «templates»
│ │ │ │ subdirectory in each of the INSTALLED_APPS.
│ │ │ │
Within the templates directory you have just created, create another
│ │ │ │ directory called polls, and within that create a file called
│ │ │ │ index.html. In other words, your template should be at
│ │ │ │ polls/templates/polls/index.html. Because of how the app_directories
│ │ │ │ template loader works as described above, you can refer to this template within
│ │ │ │ Django as polls/index.html.
That code loads the template called polls/index.html and passes it a
│ │ │ │ context. The context is a dictionary mapping template variable names to Python
│ │ │ │ objects.
│ │ │ │ -
Load the page by pointing your browser at “/polls/”, and you should see a
│ │ │ │ -bulleted-list containing the “What’s up” question from Tutorial 2. The link points to the question’s detail page.
│ │ │ │ +
Load the page by pointing your browser at «/polls/», and you should see a
│ │ │ │ +bulleted-list containing the «What’s up» question from Tutorial 2. The link points to the question’s detail page.
It’s a very common idiom to load a template, fill a context and return an
│ │ │ │ HttpResponse object with the result of the rendered
│ │ │ │ template. Django provides a shortcut. Here’s the full index() view,
│ │ │ │ rewritten:
│ │ │ │
│ │ │ │ @@ -438,15 +439,15 @@
│ │ │ │ you defined the name argument in the path() functions in
│ │ │ │ the polls.urls module, you can remove a reliance on specific URL paths
│ │ │ │ defined in your url configurations by using the {%url%} template tag:
│ │ │ │
The way this works is by looking up the URL definition as specified in the
│ │ │ │ -polls.urls module. You can see exactly where the URL name of ‘detail’ is
│ │ │ │ +polls.urls module. You can see exactly where the URL name of “detail” is
│ │ │ │ defined below:
│ │ │ │
...
│ │ │ │ # the 'name' value as called by the {% url %} template tag
│ │ │ │ path("<int:question_id>/",views.detail,name="detail"),
│ │ │ │ ...
│ │ │ │
│ │ │ │ + title="capitolo successivo">Writing your first Django app, part 4
│ │ │ │
│ │ │ │
│ │ │ │ -
Quick search
│ │ │ │ +
Ricerca veloce
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Last update:
│ │ │ │ -
Jun 26, 2024
│ │ │ │ +
giu 26, 2024
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,46 +1,46 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ WWrriittiinngg yyoouurr ffiirrsstt DDjjaannggoo aapppp,, ppaarrtt 33_?¶ ************
│ │ │ │ │ This tutorial begins where _T_u_t_o_r_i_a_l_ _2 left off. We’re continuing the web-poll
│ │ │ │ │ -application and will focus on creating the public interface – “views.”
│ │ │ │ │ +application and will focus on creating the public interface – «views.»
│ │ │ │ │ Where to get help:
│ │ │ │ │ If you’re having trouble going through this tutorial, please head over to the
│ │ │ │ │ _G_e_t_t_i_n_g_ _H_e_l_p section of the FAQ.
│ │ │ │ │ ********** OOvveerrvviieeww_?¶ **********
│ │ │ │ │ -A view is a “type” of web page in your Django application that generally serves
│ │ │ │ │ +A view is a «type» of web page in your Django application that generally serves
│ │ │ │ │ a specific function and has a specific template. For example, in a blog
│ │ │ │ │ application, you might have the following views:
│ │ │ │ │ * Blog homepage – displays the latest few entries.
│ │ │ │ │ - * Entry “detail” page – permalink page for a single entry.
│ │ │ │ │ + * Entry «detail» page – permalink page for a single entry.
│ │ │ │ │ * Year-based archive page – displays all months with entries in the given
│ │ │ │ │ year.
│ │ │ │ │ * Month-based archive page – displays all days with entries in the given
│ │ │ │ │ month.
│ │ │ │ │ * Day-based archive page – displays all entries in the given day.
│ │ │ │ │ * Comment action – handles posting comments to a given entry.
│ │ │ │ │ In our poll application, we’ll have the following four views:
│ │ │ │ │ - * Question “index” page – displays the latest few questions.
│ │ │ │ │ - * Question “detail” page – displays a question text, with no results but
│ │ │ │ │ + * Question «index» page – displays the latest few questions.
│ │ │ │ │ + * Question «detail» page – displays a question text, with no results but
│ │ │ │ │ with a form to vote.
│ │ │ │ │ - * Question “results” page – displays results for a particular question.
│ │ │ │ │ + * Question «results» page – displays results for a particular question.
│ │ │ │ │ * Vote action – handles voting for a particular choice in a particular
│ │ │ │ │ question.
│ │ │ │ │ In Django, web pages and other content are delivered by views. Each view is
│ │ │ │ │ represented by a Python function (or method, in the case of class-based views).
│ │ │ │ │ Django will choose a view by examining the URL that’s requested (to be precise,
│ │ │ │ │ the part of the URL after the domain name).
│ │ │ │ │ Now in your time on the web you may have come across such beauties as ME2/
│ │ │ │ │ Sites/dirmod.htm?sid=&type=gen&mod=Core+Pages&gid=A6CD4967199A42D9B65B1B. You
│ │ │ │ │ will be pleased to know that Django allows us much more elegant UURRLL ppaatttteerrnnss
│ │ │ │ │ than that.
│ │ │ │ │ A URL pattern is the general form of a URL - for example: /newsarchive//
│ │ │ │ │ /.
│ │ │ │ │ -To get from a URL to a view, Django uses what are known as ‘URLconfs’. A
│ │ │ │ │ +To get from a URL to a view, Django uses what are known as “URLconfs”. A
│ │ │ │ │ URLconf maps URL patterns to views.
│ │ │ │ │ This tutorial provides basic instruction in the use of URLconfs, and you can
│ │ │ │ │ refer to _U_R_L_ _d_i_s_p_a_t_c_h_e_r for more information.
│ │ │ │ │ ********** WWrriittiinngg mmoorree vviieewwss_?¶ **********
│ │ │ │ │ Now let’s add a few more views to polls/views.py. These views are slightly
│ │ │ │ │ different, because they take an argument:
│ │ │ │ │ polls/views.py_¶
│ │ │ │ │ @@ -68,28 +68,28 @@
│ │ │ │ │ # ex: /polls/5/
│ │ │ │ │ path("/", views.detail, name="detail"),
│ │ │ │ │ # ex: /polls/5/results/
│ │ │ │ │ path("/results/", views.results, name="results"),
│ │ │ │ │ # ex: /polls/5/vote/
│ │ │ │ │ path("/vote/", views.vote, name="vote"),
│ │ │ │ │ ]
│ │ │ │ │ -Take a look in your browser, at “/polls/34/”. It’ll run the detail() function
│ │ │ │ │ -and display whatever ID you provide in the URL. Try “/polls/34/results/” and “/
│ │ │ │ │ -polls/34/vote/” too – these will display the placeholder results and voting
│ │ │ │ │ +Take a look in your browser, at «/polls/34/». It’ll run the detail() function
│ │ │ │ │ +and display whatever ID you provide in the URL. Try «/polls/34/results/» and «/
│ │ │ │ │ +polls/34/vote/» too – these will display the placeholder results and voting
│ │ │ │ │ pages.
│ │ │ │ │ -When somebody requests a page from your website – say, “/polls/34/”, Django
│ │ │ │ │ +When somebody requests a page from your website – say, «/polls/34/», Django
│ │ │ │ │ will load the mysite.urls Python module because it’s pointed to by the
│ │ │ │ │ _R_O_O_T___U_R_L_C_O_N_F setting. It finds the variable named urlpatterns and traverses the
│ │ │ │ │ patterns in order. After finding the match at 'polls/', it strips off the
│ │ │ │ │ matching text ("polls/") and sends the remaining text – "34/" – to the
│ │ │ │ │ -‘polls.urls’ URLconf for further processing. There it matches '/', resulting in a call to the detail() view like so:
│ │ │ │ │ detail(request=, question_id=34)
│ │ │ │ │ The question_id=34 part comes from . Using angle brackets
│ │ │ │ │ -“captures” part of the URL and sends it as a keyword argument to the view
│ │ │ │ │ +«captures» part of the URL and sends it as a keyword argument to the view
│ │ │ │ │ function. The question_id part of the string defines the name that will be used
│ │ │ │ │ to identify the matched pattern, and the int part is a converter that
│ │ │ │ │ determines what patterns should match this part of the URL path. The colon (:
│ │ │ │ │ ) separates the converter and pattern name.
│ │ │ │ │ ********** WWrriittee vviieewwss tthhaatt aaccttuuaallllyy ddoo ssoommeetthhiinngg_?¶ **********
│ │ │ │ │ Each view is responsible for doing one of two things: returning an _H_t_t_p_R_e_s_p_o_n_s_e
│ │ │ │ │ object containing the content for the requested page, or raising an exception
│ │ │ │ │ @@ -121,15 +121,15 @@
│ │ │ │ │ code. So let’s use Django’s template system to separate the design from Python
│ │ │ │ │ by creating a template that the view can use.
│ │ │ │ │ First, create a directory called templates in your polls directory. Django will
│ │ │ │ │ look for templates in there.
│ │ │ │ │ Your project’s _T_E_M_P_L_A_T_E_S setting describes how Django will load and render
│ │ │ │ │ templates. The default settings file configures a DjangoTemplates backend whose
│ │ │ │ │ _A_P_P___D_I_R_S option is set to True. By convention DjangoTemplates looks for a
│ │ │ │ │ -“templates” subdirectory in each of the _I_N_S_T_A_L_L_E_D___A_P_P_S.
│ │ │ │ │ +«templates» subdirectory in each of the _I_N_S_T_A_L_L_E_D___A_P_P_S.
│ │ │ │ │ Within the templates directory you have just created, create another directory
│ │ │ │ │ called polls, and within that create a file called index.html. In other words,
│ │ │ │ │ your template should be at polls/templates/polls/index.html. Because of how the
│ │ │ │ │ app_directories template loader works as described above, you can refer to this
│ │ │ │ │ template within Django as polls/index.html.
│ │ │ │ │ Template namespacing
│ │ │ │ │ Now we mmiigghhtt be able to get away with putting our templates directly in polls/
│ │ │ │ │ @@ -148,15 +148,15 @@
│ │ │ │ │
│ │ │ │ │ {% endif %}
│ │ │ │ │ -Note
│ │ │ │ │ +Nota
│ │ │ │ │ To make the tutorial shorter, all template examples use incomplete HTML. In
│ │ │ │ │ your own projects you should use _c_o_m_p_l_e_t_e_ _H_T_M_L_ _d_o_c_u_m_e_n_t_s.
│ │ │ │ │ Now let’s update our index view in polls/views.py to use the template:
│ │ │ │ │ polls/views.py_¶
│ │ │ │ │ from django.http import HttpResponse
│ │ │ │ │ from django.template import loader
│ │ │ │ │
│ │ │ │ │ @@ -168,16 +168,16 @@
│ │ │ │ │ template = loader.get_template("polls/index.html")
│ │ │ │ │ context = {
│ │ │ │ │ "latest_question_list": latest_question_list,
│ │ │ │ │ }
│ │ │ │ │ return HttpResponse(template.render(context, request))
│ │ │ │ │ That code loads the template called polls/index.html and passes it a context.
│ │ │ │ │ The context is a dictionary mapping template variable names to Python objects.
│ │ │ │ │ -Load the page by pointing your browser at “/polls/”, and you should see a
│ │ │ │ │ -bulleted-list containing the “What’s up” question from _T_u_t_o_r_i_a_l_ _2. The link
│ │ │ │ │ +Load the page by pointing your browser at «/polls/», and you should see a
│ │ │ │ │ +bulleted-list containing the «What’s up» question from _T_u_t_o_r_i_a_l_ _2. The link
│ │ │ │ │ points to the question’s detail page.
│ │ │ │ │ ******** AA sshhoorrttccuutt:: _rr_ee_nn_dd_ee_rr_((_))_?¶ ********
│ │ │ │ │ It’s a very common idiom to load a template, fill a context and return an
│ │ │ │ │ _H_t_t_p_R_e_s_p_o_n_s_e object with the result of the rendered template. Django provides a
│ │ │ │ │ shortcut. Here’s the full index() view, rewritten:
│ │ │ │ │ polls/views.py_¶
│ │ │ │ │ from django.shortcuts import render
│ │ │ │ │ @@ -274,15 +274,15 @@
│ │ │ │ │ challenging to change URLs on projects with a lot of templates. However, since
│ │ │ │ │ you defined the name argument in the _p_a_t_h_(_) functions in the polls.urls module,
│ │ │ │ │ you can remove a reliance on specific URL paths defined in your url
│ │ │ │ │ configurations by using the {% url %} template tag:
│ │ │ │ │
{{ question.question_text }}
│ │ │ │ │ li>
│ │ │ │ │ The way this works is by looking up the URL definition as specified in the
│ │ │ │ │ -polls.urls module. You can see exactly where the URL name of ‘detail’ is
│ │ │ │ │ +polls.urls module. You can see exactly where the URL name of “detail” is
│ │ │ │ │ defined below:
│ │ │ │ │ ...
│ │ │ │ │ # the 'name' value as called by the {% url %} template tag
│ │ │ │ │ path("/", views.detail, name="detail"),
│ │ │ │ │ ...
│ │ │ │ │ If you want to change the URL of the polls detail view to something else,
│ │ │ │ │ perhaps to something like polls/specifics/12/ instead of doing it in the
│ │ │ │ │ @@ -329,16 +329,16 @@
│ │ │ │ │ o _W_r_i_t_e_ _v_i_e_w_s_ _t_h_a_t_ _a_c_t_u_a_l_l_y_ _d_o_ _s_o_m_e_t_h_i_n_g
│ │ │ │ │ # _A_ _s_h_o_r_t_c_u_t_:_ _r_e_n_d_e_r_(_)
│ │ │ │ │ o _R_a_i_s_i_n_g_ _a_ _4_0_4_ _e_r_r_o_r
│ │ │ │ │ # _A_ _s_h_o_r_t_c_u_t_:_ _g_e_t___o_b_j_e_c_t___o_r___4_0_4_(_)
│ │ │ │ │ o _U_s_e_ _t_h_e_ _t_e_m_p_l_a_t_e_ _s_y_s_t_e_m
│ │ │ │ │ o _R_e_m_o_v_i_n_g_ _h_a_r_d_c_o_d_e_d_ _U_R_L_s_ _i_n_ _t_e_m_p_l_a_t_e_s
│ │ │ │ │ o _N_a_m_e_s_p_a_c_i_n_g_ _U_R_L_ _n_a_m_e_s
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _D_j_a_n_g_o_ _a_p_p_,_ _p_a_r_t_ _2
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _D_j_a_n_g_o_ _a_p_p_,_ _p_a_r_t_ _4
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/intro/tutorial04.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Writing your first Django app, part 4 — Django 5.1b1 documentation
│ │ │ │ + Writing your first Django app, part 4 — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,15 +54,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
The detail() (from Tutorial 3) and results()
│ │ │ │ views are very short – and, as mentioned above, redundant. The index()
│ │ │ │ view, which displays a list of polls, is similar.
│ │ │ │
These views represent a common case of basic web development: getting data from
│ │ │ │ the database according to a parameter passed in the URL, loading a template and
│ │ │ │ returning the rendered template. Because this is so common, Django provides a
│ │ │ │ -shortcut, called the “generic views” system.
│ │ │ │ +shortcut, called the «generic views» system.
│ │ │ │
Generic views abstract common patterns to the point where you don’t even need to
│ │ │ │ write Python code to write an app. For example, the
│ │ │ │ ListView and
│ │ │ │ DetailView generic views
│ │ │ │ -abstract the concepts of “display a list of objects” and
│ │ │ │ -“display a detail page for a particular type of object” respectively.
│ │ │ │ +abstract the concepts of «display a list of objects» and
│ │ │ │ +«display a detail page for a particular type of object» respectively.
│ │ │ │
Let’s convert our poll app to use the generic views system, so we can delete a
│ │ │ │ bunch of our own code. We’ll have to take a few steps to make the conversion.
│ │ │ │ We will:
│ │ │ │
│ │ │ │
Convert the URLconf.
│ │ │ │
Delete some of the old, unneeded views.
│ │ │ │
Introduce new views based on Django’s generic views.
│ │ │ │
│ │ │ │
Read on for details.
│ │ │ │
│ │ │ │
Why the code-shuffle?
│ │ │ │
Generally, when writing a Django app, you’ll evaluate whether generic views
│ │ │ │ are a good fit for your problem, and you’ll use them from the beginning,
│ │ │ │ rather than refactoring your code halfway through. But this tutorial
│ │ │ │ -intentionally has focused on writing the views “the hard way” until now, to
│ │ │ │ +intentionally has focused on writing the views «the hard way» until now, to
│ │ │ │ focus on core concepts.
│ │ │ │
You should know basic math before you start using a calculator.
│ │ │ │ + title="capitolo successivo">Writing your first Django app, part 5
│ │ │ │
│ │ │ │
│ │ │ │ -
Quick search
│ │ │ │ +
Ricerca veloce
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Last update:
│ │ │ │ -
Jun 26, 2024
│ │ │ │ +
giu 26, 2024
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,18 +1,18 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ WWrriittiinngg yyoouurr ffiirrsstt DDjjaannggoo aapppp,, ppaarrtt 44_?¶ ************
│ │ │ │ │ This tutorial begins where _T_u_t_o_r_i_a_l_ _3 left off. We’re continuing the web-poll
│ │ │ │ │ application and will focus on form processing and cutting down our code.
│ │ │ │ │ Where to get help:
│ │ │ │ │ If you’re having trouble going through this tutorial, please head over to the
│ │ │ │ │ _G_e_t_t_i_n_g_ _H_e_l_p section of the FAQ.
│ │ │ │ │ ********** WWrriittee aa mmiinniimmaall ffoorrmm_?¶ **********
│ │ │ │ │ -Let’s update our poll detail template (“polls/detail.html”) from the last
│ │ │ │ │ +Let’s update our poll detail template («polls/detail.html») from the last
│ │ │ │ │ tutorial, so that the template contains an HTML
│ │ │ │
Let’s look at some of these more closely.
│ │ │ │
First is a question shortcut function, create_question, to take some
│ │ │ │ repetition out of the process of creating questions.
│ │ │ │
test_no_questions doesn’t create any questions, but checks the message:
│ │ │ │ -“No polls are available.” and verifies the latest_question_list is empty.
│ │ │ │ +«No polls are available.» and verifies the latest_question_list is empty.
│ │ │ │ Note that the django.test.TestCase class provides some additional
│ │ │ │ assertion methods. In these examples, we use
│ │ │ │ assertContains() and
│ │ │ │ assertQuerySetEqual().
│ │ │ │
In test_past_question, we create a question and verify that it appears in
│ │ │ │ the list.
│ │ │ │
In test_future_question, we create a question with a pub_date in the
│ │ │ │ @@ -717,15 +718,15 @@
│ │ │ │
│ │ │ │
│ │ │ │
This tutorial only introduces some of the basics of testing. There’s a great
│ │ │ │ deal more you can do, and a number of very useful tools at your disposal to
│ │ │ │ achieve some very clever things.
│ │ │ │
For example, while our tests here have covered some of the internal logic of a
│ │ │ │ -model and the way our views publish information, you can use an “in-browser”
│ │ │ │ +model and the way our views publish information, you can use an «in-browser»
│ │ │ │ framework such as Selenium to test the way your HTML actually renders in a
│ │ │ │ browser. These tools allow you to check not just the behavior of your Django
│ │ │ │ code, but also, for example, of your JavaScript. It’s quite something to see
│ │ │ │ the tests launch a browser, and start interacting with your site, as if a human
│ │ │ │ being were driving it! Django includes LiveServerTestCase
│ │ │ │ to facilitate integration with tools like Selenium.
│ │ │ │
If you have a complex application, you may want to run tests automatically
│ │ │ │ @@ -796,37 +797,37 @@
│ │ │ │
│ │ │ │ + title="capitolo successivo">Writing your first Django app, part 6
│ │ │ │
│ │ │ │
│ │ │ │ -
Quick search
│ │ │ │ +
Ricerca veloce
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Last update:
│ │ │ │ -
Jun 26, 2024
│ │ │ │ +
giu 26, 2024
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ WWrriittiinngg yyoouurr ffiirrsstt DDjjaannggoo aapppp,, ppaarrtt 55_?¶ ************
│ │ │ │ │ This tutorial begins where _T_u_t_o_r_i_a_l_ _4 left off. We’ve built a web-poll
│ │ │ │ │ application, and we’ll now create some automated tests for it.
│ │ │ │ │ Where to get help:
│ │ │ │ │ If you’re having trouble going through this tutorial, please head over to the
│ │ │ │ │ @@ -28,19 +28,19 @@
│ │ │ │ │ perhaps unnecessary. After all, our polls application is working quite happily
│ │ │ │ │ now; going through the trouble of creating automated tests is not going to make
│ │ │ │ │ it work any better. If creating the polls application is the last bit of Django
│ │ │ │ │ programming you will ever do, then true, you don’t need to know how to create
│ │ │ │ │ automated tests. But, if that’s not the case, now is an excellent time to
│ │ │ │ │ learn.
│ │ │ │ │ ****** TTeessttss wwiillll ssaavvee yyoouu ttiimmee_?¶ ******
│ │ │ │ │ -Up to a certain point, ‘checking that it seems to work’ will be a satisfactory
│ │ │ │ │ +Up to a certain point, “checking that it seems to work” will be a satisfactory
│ │ │ │ │ test. In a more sophisticated application, you might have dozens of complex
│ │ │ │ │ interactions between components.
│ │ │ │ │ A change in any of those components could have unexpected consequences on the
│ │ │ │ │ -application’s behavior. Checking that it still ‘seems to work’ could mean
│ │ │ │ │ +application’s behavior. Checking that it still “seems to work” could mean
│ │ │ │ │ running through your code’s functionality with twenty different variations of
│ │ │ │ │ your test data to make sure you haven’t broken something - not a good use of
│ │ │ │ │ your time.
│ │ │ │ │ That’s especially true when automated tests could do this for you in seconds.
│ │ │ │ │ If something’s gone wrong, tests will also assist in identifying the code
│ │ │ │ │ that’s causing the unexpected behavior.
│ │ │ │ │ Sometimes it may seem a chore to tear yourself away from your productive,
│ │ │ │ │ @@ -57,26 +57,26 @@
│ │ │ │ │ Tests change that; they light up your code from the inside, and when something
│ │ │ │ │ goes wrong, they focus light on the part that has gone wrong - eevveenn iiff yyoouu
│ │ │ │ │ hhaaddnn?’tt eevveenn rreeaalliizzeedd iitt hhaadd ggoonnee wwrroonngg.
│ │ │ │ │ ****** TTeessttss mmaakkee yyoouurr ccooddee mmoorree aattttrraaccttiivvee_?¶ ******
│ │ │ │ │ You might have created a brilliant piece of software, but you will find that
│ │ │ │ │ many other developers will refuse to look at it because it lacks tests; without
│ │ │ │ │ tests, they won’t trust it. Jacob Kaplan-Moss, one of Django’s original
│ │ │ │ │ -developers, says “Code without tests is broken by design.”
│ │ │ │ │ +developers, says «Code without tests is broken by design.»
│ │ │ │ │ That other developers want to see tests in your software before they take it
│ │ │ │ │ seriously is yet another reason for you to start writing tests.
│ │ │ │ │ ****** TTeessttss hheellpp tteeaammss wwoorrkk ttooggeetthheerr_?¶ ******
│ │ │ │ │ The previous points are written from the point of view of a single developer
│ │ │ │ │ maintaining an application. Complex applications will be maintained by teams.
│ │ │ │ │ Tests guarantee that colleagues don’t inadvertently break your code (and that
│ │ │ │ │ you don’t break theirs without knowing). If you want to make a living as a
│ │ │ │ │ Django programmer, you must be good at writing tests!
│ │ │ │ │ ********** BBaassiicc tteessttiinngg ssttrraatteeggiieess_?¶ **********
│ │ │ │ │ There are many ways to approach writing tests.
│ │ │ │ │ -Some programmers follow a discipline called “_t_e_s_t_-_d_r_i_v_e_n_ _d_e_v_e_l_o_p_m_e_n_t”; they
│ │ │ │ │ +Some programmers follow a discipline called «_t_e_s_t_-_d_r_i_v_e_n_ _d_e_v_e_l_o_p_m_e_n_t»; they
│ │ │ │ │ actually write their tests before they write their code. This might seem
│ │ │ │ │ counter-intuitive, but in fact it’s similar to what most people will often do
│ │ │ │ │ anyway: they describe a problem, then create some code to solve it. Test-driven
│ │ │ │ │ development formalizes the problem in a Python test case.
│ │ │ │ │ More often, a newcomer to testing will create some code and later decide that
│ │ │ │ │ it should have some tests. Perhaps it would have been better to write some
│ │ │ │ │ tests earlier, but it’s never too late to get started.
│ │ │ │ │ @@ -102,15 +102,15 @@
│ │ │ │ │ >>> from polls.models import Question
│ │ │ │ │ >>> # create a Question instance with pub_date 30 days in the future
│ │ │ │ │ >>> future_question = Question(pub_date=timezone.now() + datetime.timedelta
│ │ │ │ │ (days=30))
│ │ │ │ │ >>> # was it published recently?
│ │ │ │ │ >>> future_question.was_published_recently()
│ │ │ │ │ True
│ │ │ │ │ -Since things in the future are not ‘recent’, this is clearly wrong.
│ │ │ │ │ +Since things in the future are not “recent”, this is clearly wrong.
│ │ │ │ │ ******** CCrreeaattee aa tteesstt ttoo eexxppoossee tthhee bbuugg_?¶ ********
│ │ │ │ │ What we’ve just done in the _s_h_e_l_l to test for the problem is exactly what we
│ │ │ │ │ can do in an automated test, so let’s turn that into an automated test.
│ │ │ │ │ A conventional place for an application’s tests is in the application’s
│ │ │ │ │ tests.py file; the testing system will automatically find tests in any file
│ │ │ │ │ whose name begins with test.
│ │ │ │ │ Put the following in the tests.py file in the polls application:
│ │ │ │ │ @@ -394,16 +394,16 @@
│ │ │ │ │ self.assertQuerySetEqual(
│ │ │ │ │ response.context["latest_question_list"],
│ │ │ │ │ [question2, question1],
│ │ │ │ │ )
│ │ │ │ │ Let’s look at some of these more closely.
│ │ │ │ │ First is a question shortcut function, create_question, to take some repetition
│ │ │ │ │ out of the process of creating questions.
│ │ │ │ │ -test_no_questions doesn’t create any questions, but checks the message: “No
│ │ │ │ │ -polls are available.” and verifies the latest_question_list is empty. Note that
│ │ │ │ │ +test_no_questions doesn’t create any questions, but checks the message: «No
│ │ │ │ │ +polls are available.» and verifies the latest_question_list is empty. Note that
│ │ │ │ │ the _d_j_a_n_g_o_._t_e_s_t_._T_e_s_t_C_a_s_e class provides some additional assertion methods. In
│ │ │ │ │ these examples, we use _a_s_s_e_r_t_C_o_n_t_a_i_n_s_(_) and _a_s_s_e_r_t_Q_u_e_r_y_S_e_t_E_q_u_a_l_(_).
│ │ │ │ │ In test_past_question, we create a question and verify that it appears in the
│ │ │ │ │ list.
│ │ │ │ │ In test_future_question, we create a question with a pub_date in the future.
│ │ │ │ │ The database is reset for each test method, so the first question is no longer
│ │ │ │ │ there, and so again the index shouldn’t have any questions in it.
│ │ │ │ │ @@ -485,15 +485,15 @@
│ │ │ │ │ * a separate test method for each set of conditions you want to test
│ │ │ │ │ * test method names that describe their function
│ │ │ │ │ ********** FFuurrtthheerr tteessttiinngg_?¶ **********
│ │ │ │ │ This tutorial only introduces some of the basics of testing. There’s a great
│ │ │ │ │ deal more you can do, and a number of very useful tools at your disposal to
│ │ │ │ │ achieve some very clever things.
│ │ │ │ │ For example, while our tests here have covered some of the internal logic of a
│ │ │ │ │ -model and the way our views publish information, you can use an “in-browser”
│ │ │ │ │ +model and the way our views publish information, you can use an «in-browser»
│ │ │ │ │ framework such as _S_e_l_e_n_i_u_m to test the way your HTML actually renders in a
│ │ │ │ │ browser. These tools allow you to check not just the behavior of your Django
│ │ │ │ │ code, but also, for example, of your JavaScript. It’s quite something to see
│ │ │ │ │ the tests launch a browser, and start interacting with your site, as if a human
│ │ │ │ │ being were driving it! Django includes _L_i_v_e_S_e_r_v_e_r_T_e_s_t_C_a_s_e to facilitate
│ │ │ │ │ integration with tools like Selenium.
│ │ │ │ │ If you have a complex application, you may want to run tests automatically with
│ │ │ │ │ @@ -531,16 +531,16 @@
│ │ │ │ │ # _I_m_p_r_o_v_i_n_g_ _o_u_r_ _v_i_e_w
│ │ │ │ │ # _T_e_s_t_i_n_g_ _o_u_r_ _n_e_w_ _v_i_e_w
│ │ │ │ │ # _T_e_s_t_i_n_g_ _t_h_e_ _D_e_t_a_i_l_V_i_e_w
│ │ │ │ │ # _I_d_e_a_s_ _f_o_r_ _m_o_r_e_ _t_e_s_t_s
│ │ │ │ │ o _W_h_e_n_ _t_e_s_t_i_n_g_,_ _m_o_r_e_ _i_s_ _b_e_t_t_e_r
│ │ │ │ │ o _F_u_r_t_h_e_r_ _t_e_s_t_i_n_g
│ │ │ │ │ o _W_h_a_t_’_s_ _n_e_x_t_?
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _D_j_a_n_g_o_ _a_p_p_,_ _p_a_r_t_ _4
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _D_j_a_n_g_o_ _a_p_p_,_ _p_a_r_t_ _6
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/intro/tutorial06.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Writing your first Django app, part 6 — Django 5.1b1 documentation
│ │ │ │ + Writing your first Django app, part 6 — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -66,15 +67,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
This tutorial begins where Tutorial 5 left off.
│ │ │ │ We’ve built a tested web-poll application, and we’ll now add a stylesheet and
│ │ │ │ an image.
│ │ │ │
Aside from the HTML generated by the server, web applications generally need
│ │ │ │ to serve additional files — such as images, JavaScript, or CSS — necessary to
│ │ │ │ -render the complete web page. In Django, we refer to these files as “static
│ │ │ │ -files”.
│ │ │ │ +render the complete web page. In Django, we refer to these files as «static
│ │ │ │ +files».
│ │ │ │
For small projects, this isn’t a big deal, because you can keep the static
│ │ │ │ files somewhere your web server can find it. However, in bigger projects –
│ │ │ │ especially those comprised of multiple apps – dealing with the multiple sets
│ │ │ │ of static files provided by each application starts to get tricky.
│ │ │ │
That’s what django.contrib.staticfiles is for: it collects static files
│ │ │ │ from each of your applications (and any other places you specify) into a
│ │ │ │ single location that can easily be served in production.
First, create a directory called static in your polls directory. Django
│ │ │ │ will look for static files there, similarly to how Django finds templates
│ │ │ │ inside polls/templates/.
│ │ │ │
Django’s STATICFILES_FINDERS setting contains a list
│ │ │ │ of finders that know how to discover static files from various
│ │ │ │ sources. One of the defaults is AppDirectoriesFinder which
│ │ │ │ -looks for a “static” subdirectory in each of the
│ │ │ │ +looks for a «static» subdirectory in each of the
│ │ │ │ INSTALLED_APPS, like the one in polls we just created. The admin
│ │ │ │ site uses the same directory structure for its static files.
│ │ │ │
Within the static directory you have just created, create another directory
│ │ │ │ called polls and within that create a file called style.css. In other
│ │ │ │ words, your stylesheet should be at polls/static/polls/style.css. Because
│ │ │ │ of how the AppDirectoriesFinder staticfile finder works, you can refer to
│ │ │ │ this static file in Django as polls/style.css, similar to how you reference
│ │ │ │ @@ -196,15 +197,15 @@
│ │ │ │ }
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Reload http://localhost:8000/polls/ and you should see the background
│ │ │ │ loaded in the top left of the screen.
│ │ │ │
│ │ │ │ -
Warning
│ │ │ │ +
Avvertimento
│ │ │ │
The {%static%} template tag is not available for use in static files
│ │ │ │ which aren’t generated by Django, like your stylesheet. You should always
│ │ │ │ use relative paths to link your static files between each other,
│ │ │ │ because then you can change STATIC_URL (used by the
│ │ │ │ static template tag to generate its URLs) without having to modify
│ │ │ │ a bunch of paths in your static files as well.
│ │ │ │ + title="capitolo successivo">Writing your first Django app, part 7
│ │ │ │
│ │ │ │
│ │ │ │ -
Quick search
│ │ │ │ +
Ricerca veloce
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Last update:
│ │ │ │ -
Jun 26, 2024
│ │ │ │ +
giu 26, 2024
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,17 +1,17 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ WWrriittiinngg yyoouurr ffiirrsstt DDjjaannggoo aapppp,, ppaarrtt 66_?¶ ************
│ │ │ │ │ This tutorial begins where _T_u_t_o_r_i_a_l_ _5 left off. We’ve built a tested web-poll
│ │ │ │ │ application, and we’ll now add a stylesheet and an image.
│ │ │ │ │ Aside from the HTML generated by the server, web applications generally need to
│ │ │ │ │ serve additional files — such as images, JavaScript, or CSS — necessary to
│ │ │ │ │ -render the complete web page. In Django, we refer to these files as “static
│ │ │ │ │ -files”.
│ │ │ │ │ +render the complete web page. In Django, we refer to these files as «static
│ │ │ │ │ +files».
│ │ │ │ │ For small projects, this isn’t a big deal, because you can keep the static
│ │ │ │ │ files somewhere your web server can find it. However, in bigger projects –
│ │ │ │ │ especially those comprised of multiple apps – dealing with the multiple sets of
│ │ │ │ │ static files provided by each application starts to get tricky.
│ │ │ │ │ That’s what django.contrib.staticfiles is for: it collects static files from
│ │ │ │ │ each of your applications (and any other places you specify) into a single
│ │ │ │ │ location that can easily be served in production.
│ │ │ │ │ @@ -20,15 +20,15 @@
│ │ │ │ │ _G_e_t_t_i_n_g_ _H_e_l_p section of the FAQ.
│ │ │ │ │ ********** CCuussttoommiizzee yyoouurr aapppp?’ss llooookk aanndd ffeeeell_?¶ **********
│ │ │ │ │ First, create a directory called static in your polls directory. Django will
│ │ │ │ │ look for static files there, similarly to how Django finds templates inside
│ │ │ │ │ polls/templates/.
│ │ │ │ │ Django’s _S_T_A_T_I_C_F_I_L_E_S___F_I_N_D_E_R_S setting contains a list of finders that know how
│ │ │ │ │ to discover static files from various sources. One of the defaults is
│ │ │ │ │ -AppDirectoriesFinder which looks for a “static” subdirectory in each of the
│ │ │ │ │ +AppDirectoriesFinder which looks for a «static» subdirectory in each of the
│ │ │ │ │ _I_N_S_T_A_L_L_E_D___A_P_P_S, like the one in polls we just created. The admin site uses the
│ │ │ │ │ same directory structure for its static files.
│ │ │ │ │ Within the static directory you have just created, create another directory
│ │ │ │ │ called polls and within that create a file called style.css. In other words,
│ │ │ │ │ your stylesheet should be at polls/static/polls/style.css. Because of how the
│ │ │ │ │ AppDirectoriesFinder staticfile finder works, you can refer to this static file
│ │ │ │ │ in Django as polls/style.css, similar to how you reference the path for
│ │ │ │ │ @@ -70,31 +70,31 @@
│ │ │ │ │ style.css):
│ │ │ │ │ polls/static/polls/style.css_¶
│ │ │ │ │ body {
│ │ │ │ │ background: white url("images/background.png") no-repeat;
│ │ │ │ │ }
│ │ │ │ │ Reload http://localhost:8000/polls/ and you should see the background loaded in
│ │ │ │ │ the top left of the screen.
│ │ │ │ │ -Warning
│ │ │ │ │ +Avvertimento
│ │ │ │ │ The {% static %} template tag is not available for use in static files which
│ │ │ │ │ aren’t generated by Django, like your stylesheet. You should always use
│ │ │ │ │ rreellaattiivvee ppaatthhss to link your static files between each other, because then you
│ │ │ │ │ can change _S_T_A_T_I_C___U_R_L (used by the _s_t_a_t_i_c template tag to generate its URLs)
│ │ │ │ │ without having to modify a bunch of paths in your static files as well.
│ │ │ │ │ These are the bbaassiiccss. For more details on settings and other bits included with
│ │ │ │ │ the framework see _t_h_e_ _s_t_a_t_i_c_ _f_i_l_e_s_ _h_o_w_t_o and _t_h_e_ _s_t_a_t_i_c_f_i_l_e_s_ _r_e_f_e_r_e_n_c_e.
│ │ │ │ │ _D_e_p_l_o_y_i_n_g_ _s_t_a_t_i_c_ _f_i_l_e_s discusses how to use static files on a real server.
│ │ │ │ │ When you’re comfortable with the static files, read _p_a_r_t_ _7_ _o_f_ _t_h_i_s_ _t_u_t_o_r_i_a_l to
│ │ │ │ │ learn how to customize Django’s automatically-generated admin site.
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ * _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _D_j_a_n_g_o_ _a_p_p_,_ _p_a_r_t_ _6
│ │ │ │ │ o _C_u_s_t_o_m_i_z_e_ _y_o_u_r_ _aa_pp_pp_?’_ss_ _l_o_o_k_ _a_n_d_ _f_e_e_l
│ │ │ │ │ o _A_d_d_i_n_g_ _a_ _b_a_c_k_g_r_o_u_n_d_-_i_m_a_g_e
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _D_j_a_n_g_o_ _a_p_p_,_ _p_a_r_t_ _5
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _D_j_a_n_g_o_ _a_p_p_,_ _p_a_r_t_ _7
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/intro/tutorial07.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Writing your first Django app, part 7 — Django 5.1b1 documentation
│ │ │ │ + Writing your first Django app, part 7 — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -66,15 +67,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
You’ll follow this pattern – create a model admin class, then pass it as the
│ │ │ │ second argument to admin.site.register() – any time you need to change the
│ │ │ │ admin options for a model.
│ │ │ │ -
This particular change above makes the “Publication date” come before the
│ │ │ │ -“Question” field:
│ │ │ │ +
This particular change above makes the «Publication date» come before the
│ │ │ │ +«Question» field:
│ │ │ │
│ │ │ │
This isn’t impressive with only two fields, but for admin forms with dozens
│ │ │ │ of fields, choosing an intuitive order is an important usability detail.
│ │ │ │
And speaking of forms with dozens of fields, you might want to split the form
│ │ │ │ up into fieldsets:
Now “Choices” is an available option in the Django admin. The “Add choice” form
│ │ │ │ +
Now «Choices» is an available option in the Django admin. The «Add choice» form
│ │ │ │ looks like this:
│ │ │ │
│ │ │ │ -
In that form, the “Question” field is a select box containing every question in the
│ │ │ │ +
In that form, the «Question» field is a select box containing every question in the
│ │ │ │ database. Django knows that a ForeignKey should be
│ │ │ │ represented in the admin as a <select> box. In our case, only one question
│ │ │ │ exists at this point.
│ │ │ │ -
Also note the “Add another question” link next to “Question.” Every object with
│ │ │ │ +
Also note the «Add another question» link next to «Question.» Every object with
│ │ │ │ a ForeignKey relationship to another gets this for free. When you click
│ │ │ │ -“Add another question”, you’ll get a popup window with the “Add question” form.
│ │ │ │ -If you add a question in that window and click “Save”, Django will save the
│ │ │ │ +«Add another question», you’ll get a popup window with the «Add question» form.
│ │ │ │ +If you add a question in that window and click «Save», Django will save the
│ │ │ │ question to the database and dynamically add it as the selected choice on the
│ │ │ │ -“Add choice” form you’re looking at.
But, really, this is an inefficient way of adding Choice objects to the system.
│ │ │ │ It’d be better if you could add a bunch of Choices directly when you create the
│ │ │ │ Question object. Let’s make that happen.
│ │ │ │
Remove the register() call for the Choice model. Then, edit the Question
│ │ │ │ registration code to read:
This tells Django: “Choice objects are edited on the Question admin page. By
│ │ │ │ -default, provide enough fields for 3 choices.”
│ │ │ │ -
Load the “Add question” page to see how that looks:
│ │ │ │ +
This tells Django: «Choice objects are edited on the Question admin page. By
│ │ │ │ +default, provide enough fields for 3 choices.»
│ │ │ │ +
Load the «Add question» page to see how that looks:
│ │ │ │
│ │ │ │
It works like this: There are three slots for related Choices – as specified
│ │ │ │ -by extra – and each time you come back to the “Change” page for an
│ │ │ │ +by extra – and each time you come back to the «Change» page for an
│ │ │ │ already-created object, you get another three extra slots.
│ │ │ │ -
At the end of the three current slots you will find an “Add another Choice”
│ │ │ │ +
At the end of the three current slots you will find an «Add another Choice»
│ │ │ │ link. If you click on it, a new slot will be added. If you want to remove the
│ │ │ │ added slot, you can click on the X to the top right of the added slot. This
│ │ │ │ image shows an added slot:
│ │ │ │
│ │ │ │
One small problem, though. It takes a lot of screen space to display all the
│ │ │ │ fields for entering related Choice objects. For that reason, Django offers a
│ │ │ │ tabular way of displaying inline related objects. To use it, change the
│ │ │ │ @@ -237,21 +238,21 @@
│ │ │ │
With that TabularInline (instead of StackedInline), the
│ │ │ │ related objects are displayed in a more compact, table-based format:
│ │ │ │
│ │ │ │ -
Note that there is an extra “Delete?” column that allows removing rows added
│ │ │ │ -using the “Add another Choice” button and rows that have already been saved.
│ │ │ │ +
Note that there is an extra «Delete?» column that allows removing rows added
│ │ │ │ +using the «Add another Choice» button and rows that have already been saved.
Now that the Question admin page is looking good, let’s make some tweaks to the
│ │ │ │ -“change list” page – the one that displays all the questions in the system.
│ │ │ │ +«change list» page – the one that displays all the questions in the system.
│ │ │ │
Here’s what it looks like at this point:
│ │ │ │
│ │ │ │
By default, Django displays the str() of each object. But sometimes it’d be
│ │ │ │ more helpful if we could display individual fields. To do that, use the
│ │ │ │ list_display admin option, which is a
│ │ │ │ list of field names to display, as columns, on the change list page for the
│ │ │ │ object:
│ │ │ │ @@ -306,21 +307,21 @@
│ │ │ │
Edit your polls/admin.py file again and add an improvement to the
│ │ │ │ Question change list page: filters using the
│ │ │ │ list_filter. Add the following line to
│ │ │ │ QuestionAdmin:
│ │ │ │
list_filter=["pub_date"]
│ │ │ │
│ │ │ │
│ │ │ │ -
That adds a “Filter” sidebar that lets people filter the change list by the
│ │ │ │ +
That adds a «Filter» sidebar that lets people filter the change list by the
│ │ │ │ pub_date field:
│ │ │ │
│ │ │ │
The type of filter displayed depends on the type of field you’re filtering on.
│ │ │ │ Because pub_date is a DateTimeField, Django
│ │ │ │ -knows to give appropriate filter options: “Any date”, “Today”, “Past 7 days”,
│ │ │ │ -“This month”, “This year”.
This is shaping up well. Let’s add some search capability:
│ │ │ │
search_fields=["question_text"]
│ │ │ │
│ │ │ │
│ │ │ │
That adds a search box at the top of the change list. When somebody enters
│ │ │ │ search terms, Django will search the question_text field. You can use as many
│ │ │ │ fields as you’d like – although because it uses a LIKE query behind the
│ │ │ │ @@ -329,15 +330,15 @@
│ │ │ │
Clearly, having “Django administration” at the top of each admin page is
│ │ │ │ +
Clearly, having «Django administration» at the top of each admin page is
│ │ │ │ ridiculous. It’s just placeholder text.
│ │ │ │
You can change it, though, using Django’s template system. The Django admin is
│ │ │ │ powered by Django itself, and its interfaces use Django’s own template system.
Create a templates directory in your project directory (the one that
│ │ │ │ contains manage.py). Templates can live anywhere on your filesystem that
│ │ │ │ @@ -487,37 +488,37 @@
│ │ │ │
│ │ │ │ + title="capitolo successivo">Writing your first Django app, part 8
│ │ │ │
│ │ │ │
│ │ │ │ -
Quick search
│ │ │ │ +
Ricerca veloce
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Last update:
│ │ │ │ -
Jun 26, 2024
│ │ │ │ +
giu 26, 2024
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ WWrriittiinngg yyoouurr ffiirrsstt DDjjaannggoo aapppp,, ppaarrtt 77_?¶ ************
│ │ │ │ │ This tutorial begins where _T_u_t_o_r_i_a_l_ _6 left off. We’re continuing the web-poll
│ │ │ │ │ application and will focus on customizing Django’s automatically-generated
│ │ │ │ │ admin site that we first explored in _T_u_t_o_r_i_a_l_ _2.
│ │ │ │ │ Where to get help:
│ │ │ │ │ @@ -25,16 +25,16 @@
│ │ │ │ │ fields = ["pub_date", "question_text"]
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ admin.site.register(Question, QuestionAdmin)
│ │ │ │ │ You’ll follow this pattern – create a model admin class, then pass it as the
│ │ │ │ │ second argument to admin.site.register() – any time you need to change the
│ │ │ │ │ admin options for a model.
│ │ │ │ │ -This particular change above makes the “Publication date” come before the
│ │ │ │ │ -“Question” field:
│ │ │ │ │ +This particular change above makes the «Publication date» come before the
│ │ │ │ │ +«Question» field:
│ │ │ │ │ [Fields have been reordered]
│ │ │ │ │ This isn’t impressive with only two fields, but for admin forms with dozens of
│ │ │ │ │ fields, choosing an intuitive order is an important usability detail.
│ │ │ │ │ And speaking of forms with dozens of fields, you might want to split the form
│ │ │ │ │ up into fieldsets:
│ │ │ │ │ polls/admin.py_¶
│ │ │ │ │ from django.contrib import admin
│ │ │ │ │ @@ -62,26 +62,26 @@
│ │ │ │ │ polls/admin.py_¶
│ │ │ │ │ from django.contrib import admin
│ │ │ │ │
│ │ │ │ │ from .models import Choice, Question
│ │ │ │ │
│ │ │ │ │ # ...
│ │ │ │ │ admin.site.register(Choice)
│ │ │ │ │ -Now “Choices” is an available option in the Django admin. The “Add choice” form
│ │ │ │ │ +Now «Choices» is an available option in the Django admin. The «Add choice» form
│ │ │ │ │ looks like this:
│ │ │ │ │ [Choice admin page]
│ │ │ │ │ -In that form, the “Question” field is a select box containing every question in
│ │ │ │ │ +In that form, the «Question» field is a select box containing every question in
│ │ │ │ │ the database. Django knows that a _F_o_r_e_i_g_n_K_e_y should be represented in the admin
│ │ │ │ │ as a
│ │ │ │
Last update:
│ │ │ │ -
Jun 26, 2024
│ │ │ │ +
giu 26, 2024
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ WWrriittiinngg yyoouurr ffiirrsstt DDjjaannggoo aapppp,, ppaarrtt 88_?¶ ************
│ │ │ │ │ This tutorial begins where _T_u_t_o_r_i_a_l_ _7 left off. We’ve built our web-poll
│ │ │ │ │ application and will now look at third-party packages. One of Django’s
│ │ │ │ │ strengths is the rich ecosystem of third-party packages. They’re community
│ │ │ │ │ developed packages that can be used to quickly improve the feature set of an
│ │ │ │ │ @@ -28,15 +28,15 @@
│ │ │ │ │ Third-party packages that integrate with Django need some post-installation
│ │ │ │ │ setup to integrate them with your project. Often you will need to add the
│ │ │ │ │ package’s Django app to your _I_N_S_T_A_L_L_E_D___A_P_P_S setting. Some packages need other
│ │ │ │ │ changes, like additions to your URLconf (urls.py).
│ │ │ │ │ Django Debug Toolbar requires several setup steps. Follow them in _i_t_s
│ │ │ │ │ _i_n_s_t_a_l_l_a_t_i_o_n_ _g_u_i_d_e. The steps are not duplicated in this tutorial, because as a
│ │ │ │ │ third-party package, it may change separately to Django’s schedule.
│ │ │ │ │ -Once installed, you should be able to see the DjDT “handle” on the right side
│ │ │ │ │ +Once installed, you should be able to see the DjDT «handle» on the right side
│ │ │ │ │ of the browser window when you browse to http://localhost:8000/admin/. Click it
│ │ │ │ │ to open the debug toolbar and use the tools in each panel. See the _p_a_n_e_l_s
│ │ │ │ │ _d_o_c_u_m_e_n_t_a_t_i_o_n_ _p_a_g_e for more information on what the panels show.
│ │ │ │ │ ********** GGeettttiinngg hheellpp ffrroomm ootthheerrss_?¶ **********
│ │ │ │ │ At some point you will run into a problem, for example the toolbar may not
│ │ │ │ │ render. When this happens and you’re unable to resolve the issue yourself,
│ │ │ │ │ there are options available to you.
│ │ │ │ │ @@ -52,32 +52,32 @@
│ │ │ │ │ ********** IInnssttaalllliinngg ootthheerr tthhiirrdd--ppaarrttyy ppaacckkaaggeess_?¶ **********
│ │ │ │ │ There are many more third-party packages, which you can find using the
│ │ │ │ │ fantastic Django resource, _D_j_a_n_g_o_ _P_a_c_k_a_g_e_s.
│ │ │ │ │ It can be difficult to know what third-party packages you should use. This
│ │ │ │ │ depends on your needs and goals. Sometimes it’s fine to use a package that’s in
│ │ │ │ │ its alpha state. Other times, you need to know it’s production ready. _A_d_a_m
│ │ │ │ │ _J_o_h_n_s_o_n_ _h_a_s_ _a_ _b_l_o_g_ _p_o_s_t that outlines a set of characteristics that qualifies a
│ │ │ │ │ -package as “well maintained”. Django Packages shows data for some of these
│ │ │ │ │ +package as «well maintained». Django Packages shows data for some of these
│ │ │ │ │ characteristics, such as when the package was last updated.
│ │ │ │ │ As Adam points out in his post, when the answer to one of the questions is
│ │ │ │ │ -“no”, that’s an opportunity to contribute.
│ │ │ │ │ +«no», that’s an opportunity to contribute.
│ │ │ │ │ ********** WWhhaatt?’ss nneexxtt??_?¶ **********
│ │ │ │ │ The beginner tutorial ends here. In the meantime, you might want to check out
│ │ │ │ │ some pointers on _w_h_e_r_e_ _t_o_ _g_o_ _f_r_o_m_ _h_e_r_e.
│ │ │ │ │ If you are familiar with Python packaging and interested in learning how to
│ │ │ │ │ -turn polls into a “reusable app”, check out _A_d_v_a_n_c_e_d_ _t_u_t_o_r_i_a_l_:_ _H_o_w_ _t_o_ _w_r_i_t_e
│ │ │ │ │ +turn polls into a «reusable app», check out _A_d_v_a_n_c_e_d_ _t_u_t_o_r_i_a_l_:_ _H_o_w_ _t_o_ _w_r_i_t_e
│ │ │ │ │ _r_e_u_s_a_b_l_e_ _a_p_p_s.
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ * _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _D_j_a_n_g_o_ _a_p_p_,_ _p_a_r_t_ _8
│ │ │ │ │ o _I_n_s_t_a_l_l_i_n_g_ _D_j_a_n_g_o_ _D_e_b_u_g_ _T_o_o_l_b_a_r
│ │ │ │ │ o _G_e_t_t_i_n_g_ _h_e_l_p_ _f_r_o_m_ _o_t_h_e_r_s
│ │ │ │ │ o _I_n_s_t_a_l_l_i_n_g_ _o_t_h_e_r_ _t_h_i_r_d_-_p_a_r_t_y_ _p_a_c_k_a_g_e_s
│ │ │ │ │ o _W_h_a_t_’_s_ _n_e_x_t_?
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _D_j_a_n_g_o_ _a_p_p_,_ _p_a_r_t_ _7
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _A_d_v_a_n_c_e_d_ _t_u_t_o_r_i_a_l_:_ _H_o_w_ _t_o_ _w_r_i_t_e_ _r_e_u_s_a_b_l_e_ _a_p_p_s
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/intro/whatsnext.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - What to read next — Django 5.1b1 documentation
│ │ │ │ + What to read next — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -66,15 +67,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -105,52 +106,52 @@
│ │ │ │ documentation works so that you can get the most out of it.
│ │ │ │
(Yes, this is documentation about documentation. Rest assured we have no plans
│ │ │ │ to write a document about how to read the document about documentation.)
Django’s got a lot of documentation – almost 450,000 words and counting –
│ │ │ │ so finding what you need can sometimes be tricky. A good place to start
│ │ │ │ -is the Index. We also recommend using the builtin search feature.
│ │ │ │ +is the Indice. We also recommend using the builtin search feature.
│ │ │ │
Django’s main documentation is broken up into “chunks” designed to fill
│ │ │ │ +
Django’s main documentation is broken up into «chunks» designed to fill
│ │ │ │ different needs:
│ │ │ │
│ │ │ │
The introductory material is designed for people new
│ │ │ │ to Django – or to web development in general. It doesn’t cover anything
│ │ │ │ in depth, but instead gives a high-level overview of how developing in
│ │ │ │ -Django “feels”.
This is probably where you’ll want to spend most of your time; if you work
│ │ │ │ your way through these guides you should come out knowing pretty much
│ │ │ │ everything there is to know about Django.
│ │ │ │
│ │ │ │
Web development is often broad, not deep – problems span many domains.
│ │ │ │ We’ve written a set of how-to guides that answer
│ │ │ │ -common “How do I …?” questions. Here you’ll find information about
│ │ │ │ +common «How do I …?» questions. Here you’ll find information about
│ │ │ │ generating PDFs with Django, writing
│ │ │ │ custom template tags, and more.
│ │ │ │
Answers to really common questions can also be found in the FAQ.
│ │ │ │
│ │ │ │
The guides and how-to’s don’t cover every single class, function, and
│ │ │ │ method available in Django – that would be overwhelming when you’re
│ │ │ │ trying to learn. Instead, details about individual classes, functions,
│ │ │ │ methods, and modules are kept in the reference. This is
│ │ │ │ where you’ll turn to find the details of a particular function or
│ │ │ │ whatever you need.
│ │ │ │
If you are interested in deploying a project for public use, our docs have
│ │ │ │ several guides for various deployment
│ │ │ │ setups as well as a deployment checklist
│ │ │ │ for some things you’ll need to think about.
│ │ │ │ -
Finally, there’s some “specialized” documentation not usually relevant to
│ │ │ │ +
The most recent version of the Django documentation lives at
│ │ │ │ https://docs.djangoproject.com/en/dev/. These HTML pages are generated
│ │ │ │ automatically from the text files in source control. That means they reflect the
│ │ │ │ -“latest and greatest” in Django – they include the very latest corrections and
│ │ │ │ +«latest and greatest» in Django – they include the very latest corrections and
│ │ │ │ additions, and they discuss the latest Django features, which may only be
│ │ │ │ available to users of the Django development version. (See
│ │ │ │ Differences between versions below.)
│ │ │ │
We encourage you to help improve the docs by submitting changes, corrections and
│ │ │ │ suggestions in the ticket system. The Django developers actively monitor the
│ │ │ │ ticket system and use your feedback to improve the documentation for everybody.
│ │ │ │
Note, however, that tickets should explicitly relate to the documentation,
│ │ │ │ @@ -199,15 +200,15 @@
│ │ │ │ the code includes a docs/ directory, which contains all the documentation
│ │ │ │ for that release.
│ │ │ │
If you’re using the development version of Django (aka the main branch), the
│ │ │ │ docs/ directory contains all of the documentation. You can update your
│ │ │ │ Git checkout to get the latest changes.
│ │ │ │
One low-tech way of taking advantage of the text documentation is by using the
│ │ │ │ Unix grep utility to search for a phrase in all of the documentation. For
│ │ │ │ -example, this will show you each mention of the phrase “max_length” in any
│ │ │ │ +example, this will show you each mention of the phrase «max_length» in any
│ │ │ │ Django document:
The text documentation in the main branch of the Git repository contains the
│ │ │ │ -“latest and greatest” changes and additions. These changes include
│ │ │ │ +«latest and greatest» changes and additions. These changes include
│ │ │ │ documentation of new features targeted for Django’s next feature
│ │ │ │ release. For that reason, it’s worth pointing out our policy
│ │ │ │ to highlight recent changes and additions to Django.
│ │ │ │
We follow this policy:
│ │ │ │
│ │ │ │
The development documentation at https://docs.djangoproject.com/en/dev/ is
│ │ │ │ from the main branch. These docs correspond to the latest feature release,
│ │ │ │ plus whatever features have been added/changed in the framework since then.
│ │ │ │
As we add features to Django’s development version, we update the
│ │ │ │ documentation in the same Git commit transaction.
│ │ │ │
To distinguish feature changes/additions in the docs, we use the phrase:
│ │ │ │ -“New in Django Development version” for the version of Django that hasn’t
│ │ │ │ -been released yet, or “New in version X.Y” for released versions.
│ │ │ │ +«New in Django Development version» for the version of Django that hasn’t
│ │ │ │ +been released yet, or «New in version X.Y» for released versions.
│ │ │ │
Documentation fixes and improvements may be backported to the last release
│ │ │ │ branch, at the discretion of the merger, however, once a version of Django is
│ │ │ │ no longer supported, that version of the
│ │ │ │ docs won’t get any further updates.
│ │ │ │
The main documentation web page includes links to documentation for
│ │ │ │ previous versions. Be sure you are using the version of the docs
│ │ │ │ corresponding to the version of Django you are using!
│ │ │ │ + title="capitolo successivo">Writing your first contribution for Django
│ │ │ │
│ │ │ │
│ │ │ │ -
Quick search
│ │ │ │ +
Ricerca veloce
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Last update:
│ │ │ │ -
Jun 26, 2024
│ │ │ │ +
giu 26, 2024
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ WWhhaatt ttoo rreeaadd nneexxtt_?¶ ************
│ │ │ │ │ So you’ve read all the _i_n_t_r_o_d_u_c_t_o_r_y_ _m_a_t_e_r_i_a_l and have decided you’d like to
│ │ │ │ │ keep using Django. We’ve only just scratched the surface with this intro (in
│ │ │ │ │ fact, if you’ve read every single word, you’ve read about 5% of the overall
│ │ │ │ │ documentation).
│ │ │ │ │ @@ -14,42 +14,42 @@
│ │ │ │ │ as complete as possible. The rest of this document explains more about how the
│ │ │ │ │ documentation works so that you can get the most out of it.
│ │ │ │ │ (Yes, this is documentation about documentation. Rest assured we have no plans
│ │ │ │ │ to write a document about how to read the document about documentation.)
│ │ │ │ │ ********** FFiinnddiinngg ddooccuummeennttaattiioonn_?¶ **********
│ │ │ │ │ Django’s got a lloott of documentation – almost 450,000 words and counting – so
│ │ │ │ │ finding what you need can sometimes be tricky. A good place to start is the
│ │ │ │ │ -_I_n_d_e_x. We also recommend using the builtin search feature.
│ │ │ │ │ +_I_n_d_i_c_e. We also recommend using the builtin search feature.
│ │ │ │ │ Or you can just browse around!
│ │ │ │ │ ********** HHooww tthhee ddooccuummeennttaattiioonn iiss oorrggaanniizzeedd_?¶ **********
│ │ │ │ │ -Django’s main documentation is broken up into “chunks” designed to fill
│ │ │ │ │ +Django’s main documentation is broken up into «chunks» designed to fill
│ │ │ │ │ different needs:
│ │ │ │ │ * The _i_n_t_r_o_d_u_c_t_o_r_y_ _m_a_t_e_r_i_a_l is designed for people new to Django – or to
│ │ │ │ │ web development in general. It doesn’t cover anything in depth, but
│ │ │ │ │ - instead gives a high-level overview of how developing in Django “feels”.
│ │ │ │ │ + instead gives a high-level overview of how developing in Django «feels».
│ │ │ │ │ * The _t_o_p_i_c_ _g_u_i_d_e_s, on the other hand, dive deep into individual parts of
│ │ │ │ │ Django. There are complete guides to Django’s _m_o_d_e_l_ _s_y_s_t_e_m, _t_e_m_p_l_a_t_e
│ │ │ │ │ _e_n_g_i_n_e, _f_o_r_m_s_ _f_r_a_m_e_w_o_r_k, and much more.
│ │ │ │ │ This is probably where you’ll want to spend most of your time; if you
│ │ │ │ │ work your way through these guides you should come out knowing pretty
│ │ │ │ │ much everything there is to know about Django.
│ │ │ │ │ * Web development is often broad, not deep – problems span many domains.
│ │ │ │ │ - We’ve written a set of _h_o_w_-_t_o_ _g_u_i_d_e_s that answer common “How do I …?”
│ │ │ │ │ + We’ve written a set of _h_o_w_-_t_o_ _g_u_i_d_e_s that answer common «How do I …?»
│ │ │ │ │ questions. Here you’ll find information about _g_e_n_e_r_a_t_i_n_g_ _P_D_F_s_ _w_i_t_h
│ │ │ │ │ _D_j_a_n_g_o, _w_r_i_t_i_n_g_ _c_u_s_t_o_m_ _t_e_m_p_l_a_t_e_ _t_a_g_s, and more.
│ │ │ │ │ Answers to really common questions can also be found in the _F_A_Q.
│ │ │ │ │ * The guides and how-to’s don’t cover every single class, function, and
│ │ │ │ │ method available in Django – that would be overwhelming when you’re
│ │ │ │ │ trying to learn. Instead, details about individual classes, functions,
│ │ │ │ │ methods, and modules are kept in the _r_e_f_e_r_e_n_c_e. This is where you’ll turn
│ │ │ │ │ to find the details of a particular function or whatever you need.
│ │ │ │ │ * If you are interested in deploying a project for public use, our docs
│ │ │ │ │ have _s_e_v_e_r_a_l_ _g_u_i_d_e_s for various deployment setups as well as a _d_e_p_l_o_y_m_e_n_t
│ │ │ │ │ _c_h_e_c_k_l_i_s_t for some things you’ll need to think about.
│ │ │ │ │ - * Finally, there’s some “specialized” documentation not usually relevant to
│ │ │ │ │ + * Finally, there’s some «specialized» documentation not usually relevant to
│ │ │ │ │ most developers. This includes the _r_e_l_e_a_s_e_ _n_o_t_e_s and _i_n_t_e_r_n_a_l_s
│ │ │ │ │ _d_o_c_u_m_e_n_t_a_t_i_o_n for those who want to add code to Django itself, and a _f_e_w
│ │ │ │ │ _o_t_h_e_r_ _t_h_i_n_g_s_ _t_h_a_t_ _d_o_n_’_t_ _f_i_t_ _e_l_s_e_w_h_e_r_e.
│ │ │ │ │ ********** HHooww ddooccuummeennttaattiioonn iiss uuppddaatteedd_?¶ **********
│ │ │ │ │ Just as the Django code base is developed and improved on a daily basis, our
│ │ │ │ │ documentation is consistently improving. We improve documentation for several
│ │ │ │ │ reasons:
│ │ │ │ │ @@ -65,16 +65,16 @@
│ │ │ │ │ separate text file in the repository.
│ │ │ │ │ ********** WWhheerree ttoo ggeett iitt_?¶ **********
│ │ │ │ │ You can read Django documentation in several ways. They are, in order of
│ │ │ │ │ preference:
│ │ │ │ │ ******** OOnn tthhee wweebb_?¶ ********
│ │ │ │ │ The most recent version of the Django documentation lives at _h_t_t_p_s_:_/_/
│ │ │ │ │ _d_o_c_s_._d_j_a_n_g_o_p_r_o_j_e_c_t_._c_o_m_/_e_n_/_d_e_v_/. These HTML pages are generated automatically
│ │ │ │ │ -from the text files in source control. That means they reflect the “latest and
│ │ │ │ │ -greatest” in Django – they include the very latest corrections and additions,
│ │ │ │ │ +from the text files in source control. That means they reflect the «latest and
│ │ │ │ │ +greatest» in Django – they include the very latest corrections and additions,
│ │ │ │ │ and they discuss the latest Django features, which may only be available to
│ │ │ │ │ users of the Django development version. (See _D_i_f_f_e_r_e_n_c_e_s_ _b_e_t_w_e_e_n_ _v_e_r_s_i_o_n_s
│ │ │ │ │ below.)
│ │ │ │ │ We encourage you to help improve the docs by submitting changes, corrections
│ │ │ │ │ and suggestions in the _t_i_c_k_e_t_ _s_y_s_t_e_m. The Django developers actively monitor
│ │ │ │ │ the ticket system and use your feedback to improve the documentation for
│ │ │ │ │ everybody.
│ │ │ │ │ @@ -89,15 +89,15 @@
│ │ │ │ │ the code includes a docs/ directory, which contains all the documentation for
│ │ │ │ │ that release.
│ │ │ │ │ If you’re using the development version of Django (aka the main branch), the
│ │ │ │ │ docs/ directory contains all of the documentation. You can update your Git
│ │ │ │ │ checkout to get the latest changes.
│ │ │ │ │ One low-tech way of taking advantage of the text documentation is by using the
│ │ │ │ │ Unix grep utility to search for a phrase in all of the documentation. For
│ │ │ │ │ -example, this will show you each mention of the phrase “max_length” in any
│ │ │ │ │ +example, this will show you each mention of the phrase «max_length» in any
│ │ │ │ │ Django document:
│ │ │ │ │ #/ o
│ │ │ │ │ $ grep -r max_length /path/to/django/docs/
│ │ │ │ │ ...\> grep -r max_length \path\to\django\docs\
│ │ │ │ │ ******** AAss HHTTMMLL,, llooccaallllyy_?¶ ********
│ │ │ │ │ You can get a local copy of the HTML documentation following a few steps:
│ │ │ │ │ * Django’s documentation uses a system called _S_p_h_i_n_x to convert from plain
│ │ │ │ │ @@ -112,28 +112,28 @@
│ │ │ │ │ You’ll need _G_N_U_ _M_a_k_e installed for this.
│ │ │ │ │ If you’re on Windows you can alternatively use the included batch file:
│ │ │ │ │ cd path\to\django\docs
│ │ │ │ │ make.bat html
│ │ │ │ │ * The HTML documentation will be placed in docs/_build/html.
│ │ │ │ │ ********** DDiiffffeerreenncceess bbeettwweeeenn vveerrssiioonnss_?¶ **********
│ │ │ │ │ The text documentation in the main branch of the Git repository contains the
│ │ │ │ │ -“latest and greatest” changes and additions. These changes include
│ │ │ │ │ +«latest and greatest» changes and additions. These changes include
│ │ │ │ │ documentation of new features targeted for Django’s next _f_e_a_t_u_r_e_ _r_e_l_e_a_s_e. For
│ │ │ │ │ that reason, it’s worth pointing out our policy to highlight recent changes and
│ │ │ │ │ additions to Django.
│ │ │ │ │ We follow this policy:
│ │ │ │ │ * The development documentation at _h_t_t_p_s_:_/_/_d_o_c_s_._d_j_a_n_g_o_p_r_o_j_e_c_t_._c_o_m_/_e_n_/_d_e_v_/
│ │ │ │ │ is from the main branch. These docs correspond to the latest feature
│ │ │ │ │ release, plus whatever features have been added/changed in the framework
│ │ │ │ │ since then.
│ │ │ │ │ * As we add features to Django’s development version, we update the
│ │ │ │ │ documentation in the same Git commit transaction.
│ │ │ │ │ * To distinguish feature changes/additions in the docs, we use the phrase:
│ │ │ │ │ - “New in Django Development version” for the version of Django that hasn’t
│ │ │ │ │ - been released yet, or “New in version X.Y” for released versions.
│ │ │ │ │ + «New in Django Development version» for the version of Django that hasn’t
│ │ │ │ │ + been released yet, or «New in version X.Y» for released versions.
│ │ │ │ │ * Documentation fixes and improvements may be backported to the last
│ │ │ │ │ release branch, at the discretion of the merger, however, once a version
│ │ │ │ │ of Django is _n_o_ _l_o_n_g_e_r_ _s_u_p_p_o_r_t_e_d, that version of the docs won’t get any
│ │ │ │ │ further updates.
│ │ │ │ │ * The _m_a_i_n_ _d_o_c_u_m_e_n_t_a_t_i_o_n_ _w_e_b_ _p_a_g_e includes links to documentation for
│ │ │ │ │ previous versions. Be sure you are using the version of the docs
│ │ │ │ │ corresponding to the version of Django you are using!
│ │ │ │ │ @@ -143,16 +143,16 @@
│ │ │ │ │ o _H_o_w_ _t_h_e_ _d_o_c_u_m_e_n_t_a_t_i_o_n_ _i_s_ _o_r_g_a_n_i_z_e_d
│ │ │ │ │ o _H_o_w_ _d_o_c_u_m_e_n_t_a_t_i_o_n_ _i_s_ _u_p_d_a_t_e_d
│ │ │ │ │ o _W_h_e_r_e_ _t_o_ _g_e_t_ _i_t
│ │ │ │ │ # _O_n_ _t_h_e_ _w_e_b
│ │ │ │ │ # _I_n_ _p_l_a_i_n_ _t_e_x_t
│ │ │ │ │ # _A_s_ _H_T_M_L_,_ _l_o_c_a_l_l_y
│ │ │ │ │ o _D_i_f_f_e_r_e_n_c_e_s_ _b_e_t_w_e_e_n_ _v_e_r_s_i_o_n_s
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _A_d_v_a_n_c_e_d_ _t_u_t_o_r_i_a_l_:_ _H_o_w_ _t_o_ _w_r_i_t_e_ _r_e_u_s_a_b_l_e_ _a_p_p_s
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _W_r_i_t_i_n_g_ _y_o_u_r_ _f_i_r_s_t_ _c_o_n_t_r_i_b_u_t_i_o_n_ _f_o_r_ _D_j_a_n_g_o
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/misc/api-stability.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - API stability — Django 5.1b1 documentation
│ │ │ │ + API stability — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,15 +54,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Django is committed to API stability and forwards-compatibility. In a nutshell,
│ │ │ │ this means that code you develop against a version of Django will continue to
│ │ │ │ work with future releases. You may need to make minor changes when upgrading
│ │ │ │ -the version of Django your project uses: see the “Backwards incompatible
│ │ │ │ -changes” section of the release note for the version
│ │ │ │ +the version of Django your project uses: see the «Backwards incompatible
│ │ │ │ +changes» section of the release note for the version
│ │ │ │ or versions to which you are upgrading.
│ │ │ │
At the same time as making API stability a very high priority, Django is also
│ │ │ │ -committed to continual improvement, along with aiming for “one way to do it”
│ │ │ │ +committed to continual improvement, along with aiming for «one way to do it»
│ │ │ │ (eventually) in the APIs we provide. This means that when we discover clearly
│ │ │ │ superior ways to do things, we will deprecate and eventually remove the old
│ │ │ │ ways. Our aim is to provide a modern, dependable web framework of the highest
│ │ │ │ quality that encourages best practices in all projects that use it. By using
│ │ │ │ incremental improvements, we try to avoid both stagnation and large breaking
│ │ │ │ upgrades.
All the public APIs (everything in this documentation) will not be moved
│ │ │ │ or renamed without providing backwards-compatible aliases.
│ │ │ │
If new features are added to these APIs – which is quite possible –
│ │ │ │ they will not break or change the meaning of existing methods. In other
│ │ │ │ -words, “stable” does not (necessarily) mean “complete.”
│ │ │ │ +words, «stable» does not (necessarily) mean «complete.»
│ │ │ │
If, for some reason, an API declared stable must be removed or replaced, it
│ │ │ │ will be declared deprecated but will remain in the API for at least two
│ │ │ │ feature releases. Warnings will be issued when the deprecated method is
│ │ │ │ called.
│ │ │ │
See Official releases for more details on how Django’s version
│ │ │ │ numbering scheme works, and how features will be deprecated.
│ │ │ │
│ │ │ │ @@ -127,15 +128,15 @@
│ │ │ │
If we become aware of a security problem – hopefully by someone following our
│ │ │ │ security reporting policy – we’ll do
│ │ │ │ everything necessary to fix it. This might mean breaking backwards
│ │ │ │ compatibility; security trumps the compatibility guarantee.
Certain APIs are explicitly marked as “internal” in a couple of ways:
│ │ │ │ +
Certain APIs are explicitly marked as «internal» in a couple of ways:
│ │ │ │
│ │ │ │
Some documentation refers to internals and mentions them as such. If the
│ │ │ │ documentation says that something is internal, we reserve the right to
│ │ │ │ change it.
│ │ │ │
Functions, methods, and other objects prefixed by a leading underscore
│ │ │ │ (_). This is the standard Python way of indicating that something is
│ │ │ │ private; if any method starts with a single _, it’s an internal API.
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,32 +1,32 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ AAPPII ssttaabbiilliittyy_?¶ ************
│ │ │ │ │ Django is committed to API stability and forwards-compatibility. In a nutshell,
│ │ │ │ │ this means that code you develop against a version of Django will continue to
│ │ │ │ │ work with future releases. You may need to make minor changes when upgrading
│ │ │ │ │ -the version of Django your project uses: see the “Backwards incompatible
│ │ │ │ │ -changes” section of the _r_e_l_e_a_s_e_ _n_o_t_e for the version or versions to which you
│ │ │ │ │ +the version of Django your project uses: see the «Backwards incompatible
│ │ │ │ │ +changes» section of the _r_e_l_e_a_s_e_ _n_o_t_e for the version or versions to which you
│ │ │ │ │ are upgrading.
│ │ │ │ │ At the same time as making API stability a very high priority, Django is also
│ │ │ │ │ -committed to continual improvement, along with aiming for “one way to do it”
│ │ │ │ │ +committed to continual improvement, along with aiming for «one way to do it»
│ │ │ │ │ (eventually) in the APIs we provide. This means that when we discover clearly
│ │ │ │ │ superior ways to do things, we will deprecate and eventually remove the old
│ │ │ │ │ ways. Our aim is to provide a modern, dependable web framework of the highest
│ │ │ │ │ quality that encourages best practices in all projects that use it. By using
│ │ │ │ │ incremental improvements, we try to avoid both stagnation and large breaking
│ │ │ │ │ upgrades.
│ │ │ │ │ -********** WWhhaatt ?“ssttaabbllee?” mmeeaannss_?¶ **********
│ │ │ │ │ +********** WWhhaatt ?«ssttaabbllee?» mmeeaannss_?¶ **********
│ │ │ │ │ In this context, stable means:
│ │ │ │ │ * All the public APIs (everything in this documentation) will not be moved
│ │ │ │ │ or renamed without providing backwards-compatible aliases.
│ │ │ │ │ * If new features are added to these APIs – which is quite possible – they
│ │ │ │ │ will not break or change the meaning of existing methods. In other words,
│ │ │ │ │ - “stable” does not (necessarily) mean “complete.”
│ │ │ │ │ + «stable» does not (necessarily) mean «complete.»
│ │ │ │ │ * If, for some reason, an API declared stable must be removed or replaced,
│ │ │ │ │ it will be declared deprecated but will remain in the API for at least
│ │ │ │ │ two feature releases. Warnings will be issued when the deprecated method
│ │ │ │ │ is called.
│ │ │ │ │ See _O_f_f_i_c_i_a_l_ _r_e_l_e_a_s_e_s for more details on how Django’s version numbering
│ │ │ │ │ scheme works, and how features will be deprecated.
│ │ │ │ │ * We’ll only break backwards compatibility of these APIs without a
│ │ │ │ │ @@ -40,30 +40,30 @@
│ │ │ │ │ promise.
│ │ │ │ │ ******** SSeeccuurriittyy ffiixxeess_?¶ ********
│ │ │ │ │ If we become aware of a security problem – hopefully by someone following our
│ │ │ │ │ _s_e_c_u_r_i_t_y_ _r_e_p_o_r_t_i_n_g_ _p_o_l_i_c_y – we’ll do everything necessary to fix it. This might
│ │ │ │ │ mean breaking backwards compatibility; security trumps the compatibility
│ │ │ │ │ guarantee.
│ │ │ │ │ ******** AAPPIIss mmaarrkkeedd aass iinntteerrnnaall_?¶ ********
│ │ │ │ │ -Certain APIs are explicitly marked as “internal” in a couple of ways:
│ │ │ │ │ +Certain APIs are explicitly marked as «internal» in a couple of ways:
│ │ │ │ │ * Some documentation refers to internals and mentions them as such. If the
│ │ │ │ │ documentation says that something is internal, we reserve the right to
│ │ │ │ │ change it.
│ │ │ │ │ * Functions, methods, and other objects prefixed by a leading underscore
│ │ │ │ │ (_). This is the standard Python way of indicating that something is
│ │ │ │ │ private; if any method starts with a single _, it’s an internal API.
│ │ │ │ │ ******** _TT_aa_bb_ll_ee_ _oo_ff_ _CC_oo_nn_tt_ee_nn_tt_ss ********
│ │ │ │ │ * _A_P_I_ _s_t_a_b_i_l_i_t_y
│ │ │ │ │ - o _W_h_a_t_ _“_s_t_a_b_l_e_”_ _m_e_a_n_s
│ │ │ │ │ + o _W_h_a_t_ _«_s_t_a_b_l_e_»_ _m_e_a_n_s
│ │ │ │ │ o _S_t_a_b_l_e_ _A_P_I_s
│ │ │ │ │ o _E_x_c_e_p_t_i_o_n_s
│ │ │ │ │ # _S_e_c_u_r_i_t_y_ _f_i_x_e_s
│ │ │ │ │ # _A_P_I_s_ _m_a_r_k_e_d_ _a_s_ _i_n_t_e_r_n_a_l
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _M_e_t_a_-_d_o_c_u_m_e_n_t_a_t_i_o_n_ _a_n_d_ _m_i_s_c_e_l_l_a_n_y
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _D_e_s_i_g_n_ _p_h_i_l_o_s_o_p_h_i_e_s
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/misc/design-philosophies.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Design philosophies — Django 5.1b1 documentation
│ │ │ │ + Design philosophies — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,15 +54,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
A fundamental goal of Django’s stack is loose coupling and tight cohesion.
│ │ │ │ -The various layers of the framework shouldn’t “know” about each other unless
│ │ │ │ +The various layers of the framework shouldn’t «know» about each other unless
│ │ │ │ absolutely necessary.
│ │ │ │
For example, the template system knows nothing about web requests, the database
│ │ │ │ layer knows nothing about data display and the view system doesn’t care which
│ │ │ │ template system a programmer uses.
│ │ │ │
Although Django comes with a full stack for convenience, the pieces of the
│ │ │ │ stack are independent of another wherever possible.
This is a core Python principle listed in PEP 20, and it means Django
│ │ │ │ -shouldn’t do too much “magic.” Magic shouldn’t happen unless there’s a really
│ │ │ │ +shouldn’t do too much «magic.» Magic shouldn’t happen unless there’s a really
│ │ │ │ good reason for it. Magic is worth using only if it creates a huge convenience
│ │ │ │ unattainable in other ways, and it isn’t implemented in a way that confuses
│ │ │ │ developers who are trying to learn how to use the feature.
The framework should be consistent at all levels. Consistency applies to
│ │ │ │ everything from low-level (the Python coding style used) to high-level (the
│ │ │ │ -“experience” of using Django).
Fields shouldn’t assume certain behaviors based solely on the name of the
│ │ │ │ field. This requires too much knowledge of the system and is prone to errors.
│ │ │ │ Instead, behaviors should be based on keyword arguments and, in some cases, on
│ │ │ │ the type of the field.
Models should encapsulate every aspect of an “object,” following Martin
│ │ │ │ +
Models should encapsulate every aspect of an «object,» following Martin
│ │ │ │ Fowler’s Active Record design pattern.
│ │ │ │
This is why both the data represented by a model and information about
│ │ │ │ it (its human-readable name, options like default ordering, etc.) are
│ │ │ │ defined in the model class; all the information needed to understand a
│ │ │ │ given model should be stored in the model.
It should execute SQL statements as few times as possible, and it should
│ │ │ │ optimize statements internally.
│ │ │ │
This is why developers need to call save() explicitly, rather than the
│ │ │ │ framework saving things behind the scenes silently.
│ │ │ │
This is also why the select_related()QuerySet method exists. It’s an
│ │ │ │ -optional performance booster for the common case of selecting “every related
│ │ │ │ -object.”
│ │ │ │ +optional performance booster for the common case of selecting «every related
│ │ │ │ +object.»
│ │ │ │
│ │ │ │
│ │ │ │
The database API should allow rich, expressive statements in as little syntax
│ │ │ │ as possible. It should not rely on importing other modules or helper objects.
│ │ │ │
Joins should be performed automatically, behind the scenes, when necessary.
│ │ │ │
Every object should be able to access every related object, systemwide. This
│ │ │ │ @@ -202,15 +203,15 @@
│ │ │ │
File extensions in web-page URLs should be avoided.
│ │ │ │
Vignette-style commas in URLs deserve severe punishment.
Technically, foo.com/bar and foo.com/bar/ are two different URLs, and
│ │ │ │ search-engine robots (and some web traffic-analyzing tools) would treat them as
│ │ │ │ -separate pages. Django should make an effort to “normalize” URLs so that
│ │ │ │ +separate pages. Django should make an effort to «normalize» URLs so that
│ │ │ │ search-engine robots don’t get confused.
│ │ │ │
This is the reasoning behind the APPEND_SLASH setting.
Views should have access to a request object – an object that stores metadata
│ │ │ │ about the current request. The object should be passed directly to a view
│ │ │ │ function, rather than the view function having to access the request data from
│ │ │ │ a global variable. This makes it light, clean and easy to test views by passing
│ │ │ │ -in “fake” request objects.
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1,18 +1,18 @@
│ │ │ │ │ -************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_tt_ii_oo_nn ************
│ │ │ │ │ +************ _DD_jj_aa_nn_gg_oo_ _55_.._11_bb_11_ _dd_oo_cc_uu_mm_ee_nn_tt_aa_zz_ii_oo_nn_ee ************
│ │ │ │ │ _H_o_m_e | _T_a_b_l_e_ _o_f_ _c_o_n_t_e_n_t_s | _I_n_d_e_x | _M_o_d_u_l_e_s
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ │ │ ************ DDeessiiggnn pphhiilloossoopphhiieess_?¶ ************
│ │ │ │ │ This document explains some of the fundamental philosophies Django’s developers
│ │ │ │ │ have used in creating the framework. Its goal is to explain the past and guide
│ │ │ │ │ the future.
│ │ │ │ │ ********** OOvveerraallll_?¶ **********
│ │ │ │ │ ******** LLoooossee ccoouupplliinngg_?¶ ********
│ │ │ │ │ A fundamental goal of Django’s stack is _l_o_o_s_e_ _c_o_u_p_l_i_n_g_ _a_n_d_ _t_i_g_h_t_ _c_o_h_e_s_i_o_n. The
│ │ │ │ │ -various layers of the framework shouldn’t “know” about each other unless
│ │ │ │ │ +various layers of the framework shouldn’t «know» about each other unless
│ │ │ │ │ absolutely necessary.
│ │ │ │ │ For example, the template system knows nothing about web requests, the database
│ │ │ │ │ layer knows nothing about data display and the view system doesn’t care which
│ │ │ │ │ template system a programmer uses.
│ │ │ │ │ Although Django comes with a full stack for convenience, the pieces of the
│ │ │ │ │ stack are independent of another wherever possible.
│ │ │ │ │ ******** LLeessss ccooddee_?¶ ********
│ │ │ │ │ @@ -24,48 +24,48 @@
│ │ │ │ │ of web development fast. Django should allow for incredibly quick web
│ │ │ │ │ development.
│ │ │ │ │ ******** DDoonn?’tt rreeppeeaatt yyoouurrsseellff ((DDRRYY))_?¶ ********
│ │ │ │ │ Every distinct concept and/or piece of data should live in one, and only one,
│ │ │ │ │ place. Redundancy is bad. Normalization is good.
│ │ │ │ │ The framework, within reason, should deduce as much as possible from as little
│ │ │ │ │ as possible.
│ │ │ │ │ -See also
│ │ │ │ │ +Vedi anche
│ │ │ │ │ The _d_i_s_c_u_s_s_i_o_n_ _o_f_ _D_R_Y_ _o_n_ _t_h_e_ _P_o_r_t_l_a_n_d_ _P_a_t_t_e_r_n_ _R_e_p_o_s_i_t_o_r_y
│ │ │ │ │ ******** EExxpplliicciitt iiss bbeetttteerr tthhaann iimmpplliicciitt_?¶ ********
│ │ │ │ │ This is a core Python principle listed in _PP_EE_PP_ _22_00, and it means Django shouldn’t
│ │ │ │ │ -do too much “magic.” Magic shouldn’t happen unless there’s a really good reason
│ │ │ │ │ +do too much «magic.» Magic shouldn’t happen unless there’s a really good reason
│ │ │ │ │ for it. Magic is worth using only if it creates a huge convenience unattainable
│ │ │ │ │ in other ways, and it isn’t implemented in a way that confuses developers who
│ │ │ │ │ are trying to learn how to use the feature.
│ │ │ │ │ ******** CCoonnssiisstteennccyy_?¶ ********
│ │ │ │ │ The framework should be consistent at all levels. Consistency applies to
│ │ │ │ │ everything from low-level (the Python coding style used) to high-level (the
│ │ │ │ │ -“experience” of using Django).
│ │ │ │ │ +«experience» of using Django).
│ │ │ │ │ ********** MMooddeellss_?¶ **********
│ │ │ │ │ ******** EExxpplliicciitt iiss bbeetttteerr tthhaann iimmpplliicciitt_?¶ ********
│ │ │ │ │ Fields shouldn’t assume certain behaviors based solely on the name of the
│ │ │ │ │ field. This requires too much knowledge of the system and is prone to errors.
│ │ │ │ │ Instead, behaviors should be based on keyword arguments and, in some cases, on
│ │ │ │ │ the type of the field.
│ │ │ │ │ ******** IInncclluuddee aallll rreelleevvaanntt ddoommaaiinn llooggiicc_?¶ ********
│ │ │ │ │ -Models should encapsulate every aspect of an “object,” following Martin
│ │ │ │ │ +Models should encapsulate every aspect of an «object,» following Martin
│ │ │ │ │ Fowler’s _A_c_t_i_v_e_ _R_e_c_o_r_d design pattern.
│ │ │ │ │ This is why both the data represented by a model and information about it (its
│ │ │ │ │ human-readable name, options like default ordering, etc.) are defined in the
│ │ │ │ │ model class; all the information needed to understand a given model should be
│ │ │ │ │ stored iinn the model.
│ │ │ │ │ ********** DDaattaabbaassee AAPPII_?¶ **********
│ │ │ │ │ The core goals of the database API are:
│ │ │ │ │ ******** SSQQLL eeffffiicciieennccyy_?¶ ********
│ │ │ │ │ It should execute SQL statements as few times as possible, and it should
│ │ │ │ │ optimize statements internally.
│ │ │ │ │ This is why developers need to call save() explicitly, rather than the
│ │ │ │ │ framework saving things behind the scenes silently.
│ │ │ │ │ This is also why the select_related() QuerySet method exists. It’s an optional
│ │ │ │ │ -performance booster for the common case of selecting “every related object.”
│ │ │ │ │ +performance booster for the common case of selecting «every related object.»
│ │ │ │ │ ******** TTeerrssee,, ppoowweerrffuull ssyynnttaaxx_?¶ ********
│ │ │ │ │ The database API should allow rich, expressive statements in as little syntax
│ │ │ │ │ as possible. It should not rely on importing other modules or helper objects.
│ │ │ │ │ Joins should be performed automatically, behind the scenes, when necessary.
│ │ │ │ │ Every object should be able to access every related object, systemwide. This
│ │ │ │ │ access should work both ways.
│ │ │ │ │ ******** OOppttiioonn ttoo ddrroopp iinnttoo rraaww SSQQLL eeaassiillyy,, wwhheenn nneeeeddeedd_?¶ ********
│ │ │ │ │ @@ -86,15 +86,15 @@
│ │ │ │ │ The framework should make it just as easy (or even easier) for a developer to
│ │ │ │ │ design pretty URLs than ugly ones.
│ │ │ │ │ File extensions in web-page URLs should be avoided.
│ │ │ │ │ Vignette-style commas in URLs deserve severe punishment.
│ │ │ │ │ ******** DDeeffiinniittiivvee UURRLLss_?¶ ********
│ │ │ │ │ Technically, foo.com/bar and foo.com/bar/ are two different URLs, and search-
│ │ │ │ │ engine robots (and some web traffic-analyzing tools) would treat them as
│ │ │ │ │ -separate pages. Django should make an effort to “normalize” URLs so that
│ │ │ │ │ +separate pages. Django should make an effort to «normalize» URLs so that
│ │ │ │ │ search-engine robots don’t get confused.
│ │ │ │ │ This is the reasoning behind the _A_P_P_E_N_D___S_L_A_S_H setting.
│ │ │ │ │ ********** TTeemmppllaattee ssyysstteemm_?¶ **********
│ │ │ │ │ ******** SSeeppaarraattee llooggiicc ffrroomm pprreesseennttaattiioonn_?¶ ********
│ │ │ │ │ We see a template system as a tool that controls presentation and presentation-
│ │ │ │ │ related logic – and that’s it. The template system shouldn’t support
│ │ │ │ │ functionality that goes beyond this basic goal.
│ │ │ │ │ @@ -140,15 +140,15 @@
│ │ │ │ │ Writing a view should be as simple as writing a Python function. Developers
│ │ │ │ │ shouldn’t have to instantiate a class when a function will do.
│ │ │ │ │ ******** UUssee rreeqquueesstt oobbjjeeccttss_?¶ ********
│ │ │ │ │ Views should have access to a request object – an object that stores metadata
│ │ │ │ │ about the current request. The object should be passed directly to a view
│ │ │ │ │ function, rather than the view function having to access the request data from
│ │ │ │ │ a global variable. This makes it light, clean and easy to test views by passing
│ │ │ │ │ -in “fake” request objects.
│ │ │ │ │ +in «fake» request objects.
│ │ │ │ │ ******** LLoooossee ccoouupplliinngg_?¶ ********
│ │ │ │ │ A view shouldn’t care about which template system the developer uses – or even
│ │ │ │ │ whether a template system is used at all.
│ │ │ │ │ ******** DDiiffffeerreennttiiaattee bbeettwweeeenn GGEETT aanndd PPOOSSTT_?¶ ********
│ │ │ │ │ GET and POST are distinct; developers should explicitly use one or the other.
│ │ │ │ │ The framework should make it easy to distinguish between GET and POST data.
│ │ │ │ │ ********** CCaacchhee FFrraammeewwoorrkk_?¶ **********
│ │ │ │ │ @@ -199,16 +199,16 @@
│ │ │ │ │ # _U_s_e_ _r_e_q_u_e_s_t_ _o_b_j_e_c_t_s
│ │ │ │ │ # _L_o_o_s_e_ _c_o_u_p_l_i_n_g
│ │ │ │ │ # _D_i_f_f_e_r_e_n_t_i_a_t_e_ _b_e_t_w_e_e_n_ _G_E_T_ _a_n_d_ _P_O_S_T
│ │ │ │ │ o _C_a_c_h_e_ _F_r_a_m_e_w_o_r_k
│ │ │ │ │ # _L_e_s_s_ _c_o_d_e
│ │ │ │ │ # _C_o_n_s_i_s_t_e_n_c_y
│ │ │ │ │ # _E_x_t_e_n_s_i_b_i_l_i_t_y
│ │ │ │ │ -****** PPrreevviioouuss ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo pprreecceeddeennttee ******
│ │ │ │ │ _A_P_I_ _s_t_a_b_i_l_i_t_y
│ │ │ │ │ -****** NNeexxtt ttooppiicc ******
│ │ │ │ │ +****** AArrggoommeennttoo ssuucccceessssiivvoo ******
│ │ │ │ │ _T_h_i_r_d_-_p_a_r_t_y_ _d_i_s_t_r_i_b_u_t_i_o_n_s_ _o_f_ _D_j_a_n_g_o
│ │ │ │ │ -******** QQuuiicckk sseeaarrcchh ********
│ │ │ │ │ -[q ][Go]
│ │ │ │ │ +******** RRiicceerrccaa vveellooccee ********
│ │ │ │ │ +[q ][Vai]
│ │ │ │ │ ******** LLaasstt uuppddaattee:: ********
│ │ │ │ │ -Jun 26, 2024
│ │ │ │ │ +giu 26, 2024
│ │ │ │ │ « _p_r_e_v_i_o_u_s | _u_p | _n_e_x_t »
│ │ │ ├── ./usr/share/doc/python-django-doc/html/misc/distributions.html
│ │ │ │ @@ -1,22 +1,23 @@
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Third-party distributions of Django — Django 5.1b1 documentation
│ │ │ │ + Third-party distributions of Django — Django 5.1b1 documentazione
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │ -
│ │ │ │ -
│ │ │ │ +
│ │ │ │ +
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -53,15 +54,15 @@
│ │ │ │ })(jQuery);
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Documentation that we can’t find a more organized place for. Like that drawer in
│ │ │ │ your kitchen with the scissors, batteries, duct tape, and other junk.