FIleField(null=True) (Was: Guardrails around lack of model validation on blank=True fields)
Hi all,
related to these tickets I want to remind this old ticket
https://code.djangoproject.com/ticket/10244 which needs a decision.
Thanks!
On Sun, Jul 25, 2021 at 3:12 PM Jacob Walls
wrote:
> Hi group,
>
> We have several accepted tickets regarding developer headaches when a
> blank=True field, which skips model validation by design[1], contains
> inappropriate empty values (e.g. None for a not-nullable field or the empty
> string where empty strings aren't allowed). I want to see what the
> community thinks is reasonable here and move them to a resolution or
> potentially wontfix them.
>
> # 4 — CharField <http://code.djangoproject.com/ticket/4> (None
> from an application/json encoded payload isn’t cleaned to empty string)
>
> # 27697 — JSONField <http://code.djangoproject.com/ticket/27697> (None
> isn’t cleaned to “{}”)
>
> # 20205 — PositiveIntegerField
> <http://code.djangoproject.com/ticket/20205> (empty string unexpectedly
> passes model validation if blank=True. In this case the user was opting-in
> to model validation.)
>
> ***
>
> For 4—CharField—we could take Simon’s proposal
> <https://code.djangoproject.com/ticket/4#comment:5> to last-minute
> cast None to empty string in get_db_prep_value() if the field’s
> empty_strings_allowed is True and null=False.
>
> For 27696—JSONField—similarly, we could cast from None to "{}" if
> null=False.
>
> For 20205—PositiveIntegerField, and by extension, any field where
> empty_strings_allowed is False—we might run model validation if we have an
> empty string to ensure we fail at the model level instead of the db,
> although this is not the usual practice for blank=True fields. See PR
> <https://github.com/django/django/pull/14666>.
>
> The backwards compatibility concerns seem limited, because users are
> presumably working around these edge cases today, since invalid data is not
> being saved to the database. But there is the question of how much effort
> to expend here. I’m willing to see these through if we have a consensus
> around the best way to proceed.
>
> All best,
>
> Jacob
>
>
> [1] blank=True and null=False and injecting-data-before-save being an
> idiom we don’t want to remove, see:
> https://code.djangoproject.com/ticket/4#comment:7
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/58616ad3-54b6-4b21-b252-96040680fa04n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/58616ad3-54b6-4b21-b252-96040680fa04n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
--
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CABgH4JszmWeVtNgwtKB2-JbqOg9ggdGQypzFqToJeoBo%3D-Y8HA%40mail.gmail.com.
Re: Do people actually squash migrations?
On Wed, May 12, 2021 at 2:50 AM 'Mike Lissner' via Django developers (Contributions to Django itself) wrote: > So, my question is: Do people actually use squashmigrations with success? For what is worth: yes. The only problem I have is a pbcak problem (I like to do esoteric things just because). -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4Jts6Xaxa5B9Awha3Ey%3DC8c1KMowtDPA%2BrPREZCbGRnEJA%40mail.gmail.com.
Re: Status of 3.1 release blockers.
On Fri, Jul 31, 2020 at 12:23 PM Raffaele Salmaso wrote: > On Fri, Jul 31, 2020 at 12:12 PM Carlton Gibson > wrote: > What about: > retry django 3.1 * add a global settings set to sha1 * configure settings template to use sha256 so a new project will start with new algorithm * add a warning to sha1 usage and instruction how to upgrade django 3.2 * set global setting set to sha256 django 4.0 * remove setting -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4JtF%3DB2sX%3Dv%2B3twh0BMHpQcXGCvxnnNzuZFU7B%2BYSH5PVw%40mail.gmail.com.
Re: Status of 3.1 release blockers.
On Fri, Jul 31, 2020 at 12:34 PM Markus Holtermann wrote: > No, it won't move the problem to 3.2. The problem is that 3.0 only knows > about sha1. 3.1 and later know about sha1 and sha256. Meaning, any > >=3.1,<4.0 version can decode and verify signed data from 4.0 and before. > Sorry, s/3.2/3.1/ in all emails -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4JsQ23qQQUctCzVPkhfS-U2zWJHfrKBQ%2B59g1ivzj5ohcg%40mail.gmail.com.
Re: Status of 3.1 release blockers.
On Fri, Jul 31, 2020 at 12:12 PM Carlton Gibson wrote: > Yes, perhaps: default to the future sounds better. > What about: django 3.2 * add a global settings set to sha1 * configure settings template to use sha256 so a new project will start with new algorithm * add a warning to sha1 usage and instruction how to upgrade django 4.0 * remove setting -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4JtZhcQASb%3DPnaxr%3DzqvAn2XhJJAvNOu%2BQez7E%3DHyTCKWw%40mail.gmail.com.
Re: Status of 3.1 release blockers.
On Fri, Jul 31, 2020 at 11:47 AM Carlton Gibson wrote: > Add the new setting default to sha1. > Raise a DeprecationWarning unless it’s set to sha256 (so folks can opt-in > to the future.) > Remove setting, and change default to sha256, when 4.0? > > Does that sound right? (Grrr.) > I think this just move the migration problem from 3.2 to 4.0. What about the other way: add a migration setting set to new algorithm, so who really need sha1 can opt-in to old algorithm? -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4Jt0xXzXrFO8vAFFbF_zabF6xhFGnnTS1rJi_iWAT9fJRg%40mail.gmail.com.
Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META
For me it's a good move (the best would be to have request.data as with
DRF).
I've done this kind of "upgrade" from Django request.{GET,POST} to DRF
request.{query_params,data} and it was quite trivial (search and replace).
At the same time it forced me to check the code for correctnes, and I found
a couple of (unrelated) bugs.
For me I'll add the alias as soon as possible (3.1?), use them in
documentation, and start the deprecation after an LTS release (4.0? 5.0?),
so there would be plenty of time to upgrade.
On Tue, May 5, 2020 at 11:26 PM Adam Johnson wrote:
> request.GET and request.POST are misleadingly named:
>
>- GET contains the URL parameters and is therefore available whatever
>the request method. This often confuses beginners and “returners” alike.
>- POST contains form data on POST requests, but not other kinds of
>data from POST requests. It can confuse users who are posting JSON or other
>formats.
>
> Additionally both names can lead users to think e.g. "if request.GET:"
> means "if this is a GET request", which is not true.
>
> I believe the CAPITALIZED naming style was inherited from PHP's global
> variables $_GET, $_POST, $_FILES etc. (
> https://www.php.net/manual/en/reserved.variables.get.php ). It stands out
> as unpythonic, since these are instance variables and not module-level
> constants (as per PEP8 https://www.python.org/dev/peps/pep-0008/#constants
> ).
>
> I therefore propose these renames:
>
>- request.GET -> request.query_params (to match Django Rest Framework
>- see below)
>- request.POST -> request.form_data
>- request.FILES -> request.files
>- request.COOKIES -> request.cookies
>- request.META -> request.meta
>
> Since these are very core attributes and the change would cause a huge
> amount of churn, I propose not deprecating the old aliases immediately, but
> leaving them in with a documentation note that they "may be deprecated."
> Perhaps they can be like url() or ifequal which came up on the mailing list
> recently - put through the normal deprecation path after a few releases
> with such a note.
>
> Django Rest Framework already aliases GET as request.query_params in its
> request wrapper:
> https://www.django-rest-framework.org/api-guide/requests/#query_params .
> Therefore the name request.query_params should not be surprising. DRF also
> provides request.data which combines request.POST and request.FILES, and
> flexibly parses from different content types, but I'm not sure that's
> feasible to implement in Django core.
>
> For reference, other Python web frameworks have more "Pythonic" naming:
>
>- Bottle: request.url_args, request.forms, request.files,
>request.cookies, request.environ
>- Flask: request.args, request.form, request.files, request.cookies,
>request.environ
>- Starlette: request.query_params, request.form(),
>request.form()[field_name], request.cookies, scope
>
> One more note for those who might think such core attributes should be
> left alone: Django 2.2 added request.headers as a way of accessing headers
> by name. This is convenient as it avoids the need to transform the header
> to the WSGI environ name. makes the code more readable, and in the process
> reduces the potential for bugs. I believe this proposal is in the same vein.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3%2BUucViDezhkWrFsk6ZsKViWjOgtA5aBm9pnzozdc%2Beg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM3%2BUucViDezhkWrFsk6ZsKViWjOgtA5aBm9pnzozdc%2Beg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
--
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CABgH4Jvf7J0JOtdnXVGrR1Sg7-Q1q7TbUcGswMvmKKw-AwPd%3Dg%40mail.gmail.com.
Re: GDAPS
Hi, just noted this discussion... On Sun, Jan 12, 2020 at 9:42 PM Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello > I created a PR for this: https://github.com/django/django/pull/12310 > > I'd love to get some feedback on the design before I polish the patch. > I've left a comment in PR, but maybe here is more appropriate for general discussion: please, don't add other magic or special cases... I'm for deprecate and remove the default_app_config and have only one way to add an application. Thanks -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4Jt3ZjiUY0U4R8GLmqejp23%2B9Ew_952TyRcWG%2BaNfpfxZQ%40mail.gmail.com.
Re: Pre-proposal: adopt dj-database-url as a DEP 7 official project
On Thu, Jul 18, 2019 at 9:49 PM Jani Tiainen wrote: > But what happened to them since so far none of them were completed? > For my case: life :D Anyway, I'll be happy to finish it. -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4Ju%2BRBcGx%2BadqnH%2BdRKSMf%2BRD7G96Xi7F_52Pq7yA-fJ_Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Pre-proposal: adopt dj-database-url as a DEP 7 official project
Hi I'm working[¹] on https://github.com/django/django/pull/10786 which is an "evolution" of dj-database-url which handle more settings types (by default even the email settings, but it is possible to handle any other type). I'll happy to finish it. [¹] well, in my really little free time On Thu, Jul 18, 2019 at 6:45 PM Jacob Kaplan-Moss wrote: > Hi folks - > > I’d like to gauge interest in adopting dj-database-url > (http://github.com/jacobian/dj-database-url) as an official project > ( > https://github.com/django/deps/blob/master/final/0007-official-projects.rst > ). > This is my pre-proposal. I think dj-database-url is very widely-used, and > scratches a specific but annoying itch. Maintenance burden is minimal, but > important. > > What do other folks think? DEP 7 asks us to > > > solicit feedback from the community and work out if there is rough > agreement > > that the project is a good thing for Django to adopt, particularly > focusing on > > any alternative approaches to the same problem and the relative merits > of them, > > including code design, scalability, alignment with existing Django > design and > > philosophy, and having an available development and maintenance team. > > So - thoughts? > > I'm volunteering to be the shepherd, but do intend to form a larger team. > > I've also opened https://github.com/jacobian/dj-database-url/issues/120 > as another place for this discussion. Please feel free to comment either > place. > > [Backstory, and why this is living on my github right now. @kennethreitz > was > looking for a new maintainer, and reached out to me to see if Django might > be > interested. I thought perhaps so, and offered to take over maintainership > in the > meantime while we work through the DEP 7 process. If it turns out that an > Official Project is the wrong home for this, I'll either maintain it > long-term > or transfer it again.] > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/c4044098-d97f-44be-8859-b05cb594a7be%40Spark > <https://groups.google.com/d/msgid/django-developers/c4044098-d97f-44be-8859-b05cb594a7be%40Spark?utm_medium=email_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4JvLhqgd7VPPAdaCoJ3VidZ-JaPZVbU2gMiK3_Rycxnekw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19
On Mon, Feb 11, 2019 at 12:25 PM Riccardo Magliocchetti < riccardo.magliocche...@gmail.com> wrote: > InvalidTemplateLibrary: Invalid template library specified. ImportError > raised > when trying to load 'django.contrib.admin.templatetags.base': cannot > import name > getfullargspec > > 1.11.18 works fine for the same test. > Hi Riccardo, please check if you use the correct django version, django.contrib.admin.templatetags.base is there from django 2.1 -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4JtXzPVmJdJEMOqxvHS2Kc249Xcybvdmy%3DXxCqWSBj4%2Bkg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Integrate dj-database-url into Django
Hi all,
I'm working on https://github.com/django/django/pull/10786 (which is a port
of https://pypi.org/project/django-service-urls/ , which is a
'fork/rewrite' of Tom PR).
I need to (re)read all these emails to find ideas to improve the PR/package.
On Sat, Jul 28, 2018 at 9:44 PM Tom Forbes wrote:
> So in the PR I proposed I only bits I took verbatim from dj-database-url
> are the tests. The rest is re-implemented. I think it's a pretty good POC
> but I haven't touched it in a while.
>
> In any case we have to implement our own parsing for backends that do not
> support passing in a URL to the connection library.
>
> Making postgres skip our parsing step and passing it in directly is an
> implementation detail and there are much more important questions around
> the API design to answer before this has any chance of being included.
>
> On Sat, 28 Jul 2018, 12:57 Maciej Urbański, wrote:
>
>> I would agree that DSN support seems like a nicer alternative to just
>> copying dj-database-url, because it not only focuses on 12factor
>> configuration in enviroment variables, but also enables some additional
>> flexibility for the database connection option passing.
>>
>> As for 12factor, I think https://gist.github.com/telent/9742059 is a
>> good read as to why exposing as enviroment variables maybe not the best
>> motivation. Having to accommodate settings, like database connection
>> information, just so they can be fitted into single string put conveyable
>> by enviroment variable is a case in point. We likely can do the same for
>> Cache addresses as mentioned previously, although we may end up inventing
>> new URI schemes do to that.., but django overall has multitude of other
>> options that are not as easy to stringify.
>>
>> On Friday, 27 July 2018 19:14:12 UTC+2, gw...@fusionbox.com wrote:
>>>
>>> I'd like to approach this as 'support database urls in django', rather
>>> than 'copy/paste dj-database-url into django'. For postgres (I'm not sure
>>> about other backends), a database url can be passed directly to psycopg2.
>>> The postgres connection string format actually supports more features than
>>> is possible with django's HOST/USER/PORT... style settings. For example,
>>> you can pass multiple hosts and psycopg2 will attempt to connect to one of
>>> them: https://paquier.xyz/postgresql-2/postgres-10-multi-host-connstr/.
>>> Any attempt to parse the url in django will result in a loss of those
>>> features.
>>>
>>> The only problem I see is that we have to parse the database backend out
>>> of the url, and you can't pass a url like 'postgis://' to psyscopg2.
>>> I'd like to be able to do something like:
>>>
>>> DATABASES = {
>>> 'default': {
>>> 'DSN': 'postgres://',
>>> 'ENGINE': 'django.contrib.gis.db.backends.postgis',
>>> },
>>> }
>>>
>>> And let psycopg2 handle the DSN.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/1a55cc1c-ba9c-4950-ab94-50da8eec7d06%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/1a55cc1c-ba9c-4950-ab94-50da8eec7d06%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFNZOJMa1xSzBeGUYygG7nxfCVz8jUPNEiSEJhbAqLDTwga9BQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAFNZOJMa1xSzBeGUYygG7nxfCVz8jUPNEiSEJhbAqLDTwga9BQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
| Raffa
"Variables and attributes may not begin with underscores" error
Hi, anyone knows the rationale for forbidding variables and attributes with an initial underscore in django templates? This limitation is here from day 0 https://github.com/django/django/blob/ed114e15106192b22ebb78ef5bf5bce72b419d13/django/core/template.py#L261 and docs doesn't mention it (or simply I can't google it) https://docs.djangoproject.com/en/dev/ref/templates/language/#variables I've removed this check and it seem fine for the empirical tests https://github.com/django/django/blob/master/django/template/base.py#L786 If there is no objection would be ok to remove this limitation? Thaks -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4Js0kfnxcEggt%3DTF1Q3CH%3D%2Bp5DHF3YWjN%2BAHe_DrrMLM0w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: About #8500 and #27728
Hi Carlton,
On Sat, Jan 20, 2018 at 9:13 AM, Carlton Gibson <carlton.gib...@gmail.com>
wrote:
> Hi Raffaele,
>
> Thanks for both your effort and your patience.
>
> There are around 60 patches needing review (or just reviewed or being
> improved or...) at the moment, so it can take a while to get to.
>
> I will look at this issue on Monday.
>
Thanks!
> Please don't loose heart.
>
Don't worry
> Kind Regards,
>
> Carlton
>
>
> On Friday, 19 January 2018 22:41:22 UTC+1, Raffaele Salmaso wrote:
>>
>> Hi all,
>> as these PR have merge conflicts that need to be resolved, and it takes
>> time to keep that ready to merge, I would be glad to know if continue to
>> work on them (and how to get them merged) or just drop them and carry on.
>>
>> Thanks
>>
>> On Tue, Sep 5, 2017 at 10:57 AM, Raffaele Salmaso <raff...@salmaso.org>
>> wrote:
>>
>>> Hi all,
>>> I'm working to ticket #8500 and #27728 to improve a bit the admin, and
>>> being asked to ask to django-developers about some decision.
>>>
>>> In ticket #8500 I've used a LazyObject to defer the the real
>>> django.contrib.admin.sites.site instantiation, so admin.site is always
>>> the custom one.
>>> The first approach was simpler, with a setting. But as Tim pointed out
>>> it doesn't need to be a setting, so I rewrote to be a custom field for
>>> (Simple)AdminConfig (and django itself doesn't need to know it existence)
>>>
>>> Currently I'm monkey patching in my custom admin setup (
>>> https://bitbucket.org/rsalmaso/django-fluo is my own utility library)
>>>
>>> > class FluoAdminConfig(AdminConfig):
>>> > default_site = "fluo.admin.sites.AdminSite"
>>> >
>>> > def ready(self):
>>> > self.override_admin_site()
>>> > super().ready()
>>> >
>>> > def override_admin_site(self):
>>> > from django.contrib import admin as django_admin
>>> > from django.contrib.admin import sites as django_sites
>>> > from fluo import admin as fluo_admin
>>> > from fluo.admin.sites import DefaultAdminSite
>>> >
>>> > site = DefaultAdminSite()
>>>
>>> where the DefaultAdminSite is the same as in PR
>>> > class DefaultAdminSite(LazyObject):
>>> > def _setup(self):
>>> > AdminSiteClass = import_string(apps.get_app_con
>>> fig('admin').default_site)
>>> > self._wrapped = AdminSiteClass()
>>>
>>>
>>> I think it is a better approach than the Jannis' one (
>>> https://code.djangoproject.com/attachment/ticket/8500/8500.1.diff), as
>>> Adam claims it is simpler, because
>>> - it doesn't require to rewrite your admin.py to add an helper function
>>> in admin.py
>>> > def register(site):
>>> > site.register(...)
>>> - it works with all current third party modules (so don't have to add a
>>> custom adapter in my own project)
>>> - can use the @admin.register() decorator as is
>>>
>>> Currently all my projects use this approach, and I'm really happy
>>> because I find no problem with 3rd apps, they always use my custom
>>> instance, and don't have two different site.
>>>
>>> In ticket #27728 I've rewrite all include template tags (submit_row,
>>> pagination, admin_actions, search_form, date_hierarchy, result_list,
>>> prepopulated_fields_js, object_tools) to be overridable by the "standard"
>>> admin pattern (["admin/app_label/app_model/template_name",
>>> "admin/app_label/template_name", "admin/template_name"]).
>>> This patch solves even the tickets #11974, #12566, #18957, #19235,
>>> #26763.
>>> Choose to patch all include tags because:
>>> - I have a project where I override all of them (!)
>>> - they are all the same implementation, so easy to replicate
>>>
>>> The approach is to create a custom InclusionAdminNode, which handle all
>>> common task to split the include parameters, select the correct template
>>> and wrapping the original tag function (which are never changed).
>>>
>>> Hope this clears all intentions and have them in django 2.0 :)
>>>
>>> --
>>> | Raffaele Salmaso
>>> | https://salmaso.org
>>> | https://bitbucket.org/rsalmaso
>>> | https://github.com/rsalmaso
>>>
>>
&
Re: About #8500 and #27728
Hi all,
as these PR have merge conflicts that need to be resolved, and it takes
time to keep that ready to merge, I would be glad to know if continue to
work on them (and how to get them merged) or just drop them and carry on.
Thanks
On Tue, Sep 5, 2017 at 10:57 AM, Raffaele Salmaso <raffa...@salmaso.org>
wrote:
> Hi all,
> I'm working to ticket #8500 and #27728 to improve a bit the admin, and
> being asked to ask to django-developers about some decision.
>
> In ticket #8500 I've used a LazyObject to defer the the real
> django.contrib.admin.sites.site instantiation, so admin.site is always
> the custom one.
> The first approach was simpler, with a setting. But as Tim pointed out it
> doesn't need to be a setting, so I rewrote to be a custom field for
> (Simple)AdminConfig (and django itself doesn't need to know it existence)
>
> Currently I'm monkey patching in my custom admin setup (
> https://bitbucket.org/rsalmaso/django-fluo is my own utility library)
>
> > class FluoAdminConfig(AdminConfig):
> > default_site = "fluo.admin.sites.AdminSite"
> >
> > def ready(self):
> > self.override_admin_site()
> > super().ready()
> >
> > def override_admin_site(self):
> > from django.contrib import admin as django_admin
> > from django.contrib.admin import sites as django_sites
> > from fluo import admin as fluo_admin
> > from fluo.admin.sites import DefaultAdminSite
> >
> > site = DefaultAdminSite()
>
> where the DefaultAdminSite is the same as in PR
> > class DefaultAdminSite(LazyObject):
> > def _setup(self):
> > AdminSiteClass = import_string(apps.get_app_
> config('admin').default_site)
> > self._wrapped = AdminSiteClass()
>
>
> I think it is a better approach than the Jannis' one (
> https://code.djangoproject.com/attachment/ticket/8500/8500.1.diff), as
> Adam claims it is simpler, because
> - it doesn't require to rewrite your admin.py to add an helper function in
> admin.py
> > def register(site):
> > site.register(...)
> - it works with all current third party modules (so don't have to add a
> custom adapter in my own project)
> - can use the @admin.register() decorator as is
>
> Currently all my projects use this approach, and I'm really happy because
> I find no problem with 3rd apps, they always use my custom instance, and
> don't have two different site.
>
> In ticket #27728 I've rewrite all include template tags (submit_row,
> pagination, admin_actions, search_form, date_hierarchy, result_list,
> prepopulated_fields_js, object_tools) to be overridable by the "standard"
> admin pattern (["admin/app_label/app_model/template_name",
> "admin/app_label/template_name", "admin/template_name"]).
> This patch solves even the tickets #11974, #12566, #18957, #19235, #26763.
> Choose to patch all include tags because:
> - I have a project where I override all of them (!)
> - they are all the same implementation, so easy to replicate
>
> The approach is to create a custom InclusionAdminNode, which handle all
> common task to split the include parameters, select the correct template
> and wrapping the original tag function (which are never changed).
>
> Hope this clears all intentions and have them in django 2.0 :)
>
> --
> | Raffaele Salmaso
> | https://salmaso.org
> | https://bitbucket.org/rsalmaso
> | https://github.com/rsalmaso
>
--
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CABgH4JvtuEGE4kx-%2BPaAzht%2BMdGa2_w2mgj-noMqBHzDntw2Ng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
About #8500 and #27728
Hi all,
I'm working to ticket #8500 and #27728 to improve a bit the admin, and
being asked to ask to django-developers about some decision.
In ticket #8500 I've used a LazyObject to defer the the real
django.contrib.admin.sites.site instantiation, so admin.site is always the
custom one.
The first approach was simpler, with a setting. But as Tim pointed out it
doesn't need to be a setting, so I rewrote to be a custom field for
(Simple)AdminConfig (and django itself doesn't need to know it existence)
Currently I'm monkey patching in my custom admin setup (
https://bitbucket.org/rsalmaso/django-fluo is my own utility library)
> class FluoAdminConfig(AdminConfig):
> default_site = "fluo.admin.sites.AdminSite"
>
> def ready(self):
> self.override_admin_site()
> super().ready()
>
> def override_admin_site(self):
> from django.contrib import admin as django_admin
> from django.contrib.admin import sites as django_sites
> from fluo import admin as fluo_admin
> from fluo.admin.sites import DefaultAdminSite
>
> site = DefaultAdminSite()
where the DefaultAdminSite is the same as in PR
> class DefaultAdminSite(LazyObject):
> def _setup(self):
> AdminSiteClass =
import_string(apps.get_app_config('admin').default_site)
> self._wrapped = AdminSiteClass()
I think it is a better approach than the Jannis' one (
https://code.djangoproject.com/attachment/ticket/8500/8500.1.diff), as Adam
claims it is simpler, because
- it doesn't require to rewrite your admin.py to add an helper function in
admin.py
> def register(site):
> site.register(...)
- it works with all current third party modules (so don't have to add a
custom adapter in my own project)
- can use the @admin.register() decorator as is
Currently all my projects use this approach, and I'm really happy because I
find no problem with 3rd apps, they always use my custom instance, and
don't have two different site.
In ticket #27728 I've rewrite all include template tags (submit_row,
pagination, admin_actions, search_form, date_hierarchy, result_list,
prepopulated_fields_js, object_tools) to be overridable by the "standard"
admin pattern (["admin/app_label/app_model/template_name",
"admin/app_label/template_name", "admin/template_name"]).
This patch solves even the tickets #11974, #12566, #18957, #19235, #26763.
Choose to patch all include tags because:
- I have a project where I override all of them (!)
- they are all the same implementation, so easy to replicate
The approach is to create a custom InclusionAdminNode, which handle all
common task to split the include parameters, select the correct template
and wrapping the original tag function (which are never changed).
Hope this clears all intentions and have them in django 2.0 :)
--
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CABgH4JsR_T_72omhqy7xeOvyV0MYAKFZ2eE1Fb18ESVy%2BzC%2BPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Ask for PR review
Hi, as django freeze is coming next month and I have some time to work on, I would like merge these two admin PR https://github.com/django/django/pull/7765 https://github.com/django/django/pull/7840 Thanks! -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4JtdpqDUNv1bYB13TeETtQHO%2BmJ7V4Y0E0QZ85icnFHGTQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: automating Django releases
On Fri, Nov 25, 2016 at 8:49 PM, Tim Graham <timogra...@gmail.com> wrote:
> After doing releases about once a month for a while, I'm thinking it would
> be nice if releasing Django could be a bit more automated. As far as I
> know, the process hasn't changed too much in 10 years, while the state of
> Python packaging has improved.
>
> Currently doing a release requires bumping the VERSION tuple in
> django/__init__.py [0], creating tarball/wheel and checksum files, asking
> someone in IRC to verify the checks look fine, and upload files to various
> locations [1]. My idea would be to use setuptools_scm [2] (that choice
> because this is the only tool I know about) to eliminate the need to
> bump/set a VERSION tuple and instead fetch the version information based on
> git tags. Something like (based on what I found in djanog-hosts [3]):
>
> __version__ = pkg_resources.get_distribution('django').version
>
Oh, this will never work with my setup (*.dist-info are not saved).
It is always really needed the *.dist-info metadata?
Need to check this...
(just tried a sample and I can't use django-hosts for this...
pkg_resources.DistributionNotFound: The 'django-hosts' distribution was not
found and is required by the application
not nice)
One issue I'm not sure how to deal with is how to provides
> backwards-compatibility for django.VERSION, the tuple format that looks
> something like:
>
> VERSION = (1, 11, 0, 'alpha', 0)
>
> I think removing or deprecating it would be quite disruptive for the
> community as I've seen lots of third-party apps that do checks like "if
> django.VERSION < (1, 9): ...", for example. I suspect it's possible to
> parse the version string to create something similar, but I wondered if
> anyone has experience with that.
>
if tuple(map(int,
pkg_resources.get_distribution('django').version.split('.')[:2])) < (1, 11):
...
and this doesn't work for '1.10a0'
--
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CABgH4JvzUnfSF8baMG1T%2BJS%2BwsZwM60QBa0X46xXFdtRKffGyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Deprecating User.is_anonymous ?
On Sat, Apr 2, 2016 at 4:19 PM, Tim Graham <timogra...@gmail.com> wrote: > My concern is that if a project doesn't see the deprecation warnings > What about having a new property like User.authenticated (or User.anonymous)? User.is_anoymous and User.is_authenticated can be deprecate and removed from docs, leaving them in place for longer (django 3). -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4Ju981Ht-wpMZ1kyesGxCd7K6OhD5oNew8PSq8bdPR-SWw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [GSOC] Weekly update
On Fri, Jul 18, 2014 at 7:32 PM, Daniel Pyrathon <piro...@gmail.com> wrote: > *- Started on my GMail Store* > While I was waiting for review, I have started an implementation of my > GMail store. The implementation is documented here ( > https://docs.google.com/document/d/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFBkCXgy0Jwo/edit#heading=h.wyxx4xxijubt) > and will be my final deliverable. > So far, I have had some interesting results. With very little code, and > the new Options API, I didn't have to modify a single file inside Django > for my implementation to work. All code just overrides some of the main > Django classes (Manager, Query, QuerySet). > > Currently, I have managed to: > >- Browse my GMail threads through Django admin >- View a single GMail thread >- Read an entire email! >- Use the Console to do everything said above! > > I have attached a picture. > > > <https://lh3.googleusercontent.com/-br9TSK3bRXA/U8lX7kp3qeI/Lbw/nr0oHgRLkRk/s1600/png.png> > > The next step is to improve my implementation. I will be (hopefully) soon > releasing a GitHub project that you will be able to use to browse, read and > send your mail through Django admin and forms! > Pirosb3, just three words: really nice work! -- | Raffaele Salmaso | http://salmaso.org | https://bitbucket.org/rsalmaso | http://gnammo.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4Jv1N3NmARFp%3D2eiuKNFB_Zr6Bh4Db_SnL%3Dhe5TiJa%3DsXA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Renaming apps.has_app
On Sun, Jan 5, 2014 at 10:11 PM, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:
> `apps.has_app(...)` is technically correct but I think we can find a better
> name. My current favorite is `apps.installed(…)`. It’s quite short and it’s
> reminiscent of INSTALLED_APPS. That makes (some) sense since the method tests
> if its argument is in INSTALLED_APPS, accounting for AppConfigs.
>
> Since I’m awful at picking names, I’d like to hear your suggestions and
> arguments before making a decision.
apps.is_installed('django.contrib.sites') ?
Should it takes a list of apps, just to replace
apps.is_installed('djagno.contrib.sites') and
apps.is_installed('django.contrib.admin') and ...
with
apps.is_installed('django.contrib.sites', 'django.contrib.admin',...)
?
--
| Raffaele Salmaso
| http://salmaso.org
| https://bitbucket.org/rsalmaso
| http://gnammo.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CABgH4JsyoWxVUjVKdP9RO%3DL65UBC0VFbqKHFWwiEWFozVD19sA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: Django 1.2.1 released
James Bennett wrote: > announce Django 1.2.1 thanks! but when the releases/1.2.X branch will be created? -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Does Python 2.6.5 broke Django 1.1.1 Client Test?
Marcob wrote: > Please, does anybody know which patch I need to apply to 1.1.1 to fix > this strange problem? http://code.djangoproject.com/changeset/12807 ? -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
Joseph Kocherhans wrote: > Ok. I see it. ;) :D > Sorry, I've been out of town for a while with no > internet access. 12577 is near the top of my list to look at. ok thanks :D -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
Raffaele Salmaso wrote: > Joseph Kocherhans wrote: >> regressions? > http://code.djangoproject.com/ticket/12577 Hello, is anybody out there? Sorry if I seem rude, but there is a severe regression an no one care to say at least 'ok I see it', even when there is an *explicit* request for regressions... I've resolved with an horrible monkeypatch, but at least I've now a working copy of django -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
Raffaele Salmaso wrote: > Joseph Kocherhans wrote: >> regressions? > http://code.djangoproject.com/ticket/12577 Ok, BaseGenericInlineFormSet doesn't have save_new to save the generic fk.pk Reenabled and everything go as before. -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
Joseph Kocherhans wrote: > regressions? http://code.djangoproject.com/ticket/12577 -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: A bunch of little fixes
Malcolm Tredinnick wrote: > I just did a random sampling of four tickets and #10504 is a feature > addition, it can wait until 1.2 (and maybe even then isn't actually > something to do, since render_to_response is a *shortcut*, not a > complete replacement). true, not really a problem here > #10647 and #9992 are already in the 1.1 milestone > an #10528 has been fixed. amusing, they were closed almost at the same time of my mail :) no problem here again > My point being, we already have a huge list of open tickets that are > being worked on and you must be aware that we're in the lead up to a 1.1 > release. Posting a list of ticket numbers with no explanation of why > they're more important than the existing ones isn't helpful. Size > doesn't matter at this point. Sometimes the quick ones won't be fixed > first, because they're something that, by definition can be fixed in > idle moments when we're taking a break from something else, or towards > the end in a hurry. It's the problems that are big bugs requiring more > thought that have to be done first, since they are the ones that could > well take a lot longer to resolve than we can reliably estimate. > > Regards, > Malcolm yes, I was *too* concise, my bad: yes, they can wait 1.1 release (as I track trunk) but for some of them I would like to be resolved ASAP * add app_label name to related_name http://code.djangoproject.com/ticket/9638 Here we have a some abstract model which are inherited from a lot of application models, and it breaks when we have two (or more) models with the same name. Actually I've monkey patched django model.ForeignKey to use a custom contribute_to_class which bypasses the original one. I've copied what original contribute_to_class does and integrated with RelatedField.contribute_to_class, throwing away only if hasattr(sup, 'contribute_to_class'): sup.contribute_to_class(cls, name) which doesn't work. It works but it's a solution I'd really like to throw away ASAP * check action permission http://code.djangoproject.com/ticket/10609 I think this is already managed by r10408, so no more a problem here * application names i18n in admin http://code.djangoproject.com/ticket/10436 This fix a really bad situation for our customers, which have the admin site in italian language and where the model names are in italian language and the application names are in english one. They are always confused by this. Thanks for your time -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele at salmaso punto org | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
A bunch of little fixes
* add app_label name to related_name http://code.djangoproject.com/ticket/9638 * creation of m2m not managed tables http://code.djangoproject.com/ticket/10647 * avoid a js error in admin pages http://code.djangoproject.com/ticket/10651 * check action permission http://code.djangoproject.com/ticket/10609 * unicode name in unique_together http://code.djangoproject.com/ticket/10645 * pass content_type in render_to_response http://code.djangoproject.com/ticket/10504 * application names i18n in admin http://code.djangoproject.com/ticket/10436 * excluded fields can be updated http://code.djangoproject.com/ticket/10363 DOCUMENTATION = * file upload http://code.djangoproject.com/ticket/10400 * clarify get_object_or_404 parameter http://code.djangoproject.com/ticket/10709 * clarify admin reverse names http://code.djangoproject.com/ticket/10528 * **extra_parameter in test client http://code.djangoproject.com/ticket/9607 * get_profile/get_model http://code.djangoproject.com/ticket/9992 -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele at salmaso punto org | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
