Allow for strict mode in templates
I was struggeling with a get query that just wouldn't throw any exceptions. Then I stubled about this: https://code.djangoproject.com/ticket/11909 I'm so sorry about the rude request in there, but it would be really helpful to allow for a "strict mode" in templates where errors get thrown to help debug issues. -- 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/0b926630-6832-48a0-8377-c74d93c55a83n%40googlegroups.com.
Re: Make timeout property for PasswordResetTokenGenerator
Hey Carlton,
I'm reading through the replies and I feel like I'm missing point
completely.
First some background - `PasswordResetTokenGenerator` is heavily referenced
over the web (or more accurately - the `default_token_genrator`) when it
comes to account activation. I personally believe the solution is pretty
genius for this particular use case, simplifies the flow without relying on
the persistence layer. The implementation is also well-contained within the
class so makes using it super simple.
When I use `default_token_generator` I'm however limited by two things -
the fields that make up the hash (user.pk, user.password, login_timestamp
and current timestamp) - which I can EASILY overwrite with
`_make_hash_value` and `PASSWORD_RESET_TIMEOUT_DAYS` which is NOT easily
overwritten, due to the method `check_token` having too many
responsibilities.
So the use case is definitely there, but the argument here is "we don't
want to", but the reasoning behind that is unclear - is it not worth to
maintain this piece of code because it's deprecated? This would be flagged
then, no? Or do you feel like it's already a concrete implementation given
its name ("PasswordResetTokenGenerator") - would the solution then be
abstracting the parts of it to a base class, would that be acceptable?
On Tuesday, 23 August 2022 at 13:47:45 UTC+2 carlton...@gmail.com wrote:
> Yes, likely.
>
> My point was (merely) that we **don't** want to add
> additional extension points to PasswordResetTokenGenerator.
>
> On Tue, 23 Aug 2022 at 12:58, Roger Gammans
> wrote:
>
>> Hi
>>
>> If it's intended as a reference implementation, then I would expect
>> PasswordResetTokenGenerator to use Signer or TimestampSigner internally
>> , but I was surprised to discover that it didn't use either.
>>
>> Isn't those entry points the better API to advise for use rather than the
>> direct use of hmac based algorithms?
>>
>> On Tue, 2022-08-23 at 12:45 +0200, Carlton Gibson wrote:
>>
>> Hi Alexander.
>>
>> I think the point from ticket #30423 is that we don't want to complicate
>> PasswordResetTokenGenerator in order to make it into a more general
>> purpose token generator.
>> Much better is for you to take inspiration from it to implement what you
>> need in your project. (It's the underlying signing code that you really
>> want to lean on Django for.)
>>
>> Kind Regards,
>>
>> Carlton
>>
>> On Mon, 22 Aug 2022 at 17:26, Alexander Voloshchenko <
>> voloshchen...@gmail.com> wrote:
>>
>> During project development our team needs to create several types of
>> tokens. One of them will be used in case of account reset password. The
>> second one is for account activation. Django itself has a good class for
>> token generation called PasswordResetTokenGenerator. And now for account
>> activation, we are using our own class called ActivationTokenGenerator,
>> a subclass of PasswordResetTokenGenerator with overridden
>> _make_hash_value method. And it works, but there is one problem. And
>> this problem is called "timeout". For now, every token created with
>> PasswordResetTokenGenerator will have timeout from
>> settings.PASSWORD_RESET_TIMEOUT variable and can be changed only by
>> changing this variable value. But what if we need different timeouts for
>> different tokens? And I don't think we want changing timeout for
>> *activation* token using a variable which is screaming about *password
>> reset* (PASSWORD_RESET_TIMEOUT), we would like to use smth called
>> ACTIVATION_TOKEN_TIMEOUT
>> So there is a solution: why not create a timeout property for
>> PasswordResetTokenGenerator class? Almost in the same way as it was done
>> with _secret and algorithm fields.So our development team come up with
>> an idea to create a PR which will add this functionality to the Django
>> project. But before this we decided to search similar solutions in django
>> PRs. And we found them! Ticket 30423
>> https://code.djangoproject.com/ticket/30423 sounds good enough, but it
>> was closed with wontfix label.So the question is: why not to add this
>> fine feature to the PasswordResetTokenGenerator ? And if people find
>> this useful - why not to merge one o the existing PRs?
>>
>> --
>>
> 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-develop...@g
Django project website UX: call for help!
Hello everyone, at 20tab we just finished collaborating with the Django Software Foundation to improve the Django project website's accessibility and usability. We now need you to help us understand how involved people are in the Django project and how much they care for good UX. Fill out this very short form and let us know! https://t.co/cWiMc6SJPB Thank you to all of you who will take the time to respond - your input is of immense value to us. Feel free to raise any questions here. -- 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/76615d60-853a-45a7-b4a6-b75f85d808b5n%40googlegroups.com.
Discussion regarding #32628 and #32823
Dear community, I am writing to this group as a last resort and as advised (twice) by Mariusz Felisiak. I have several points to make. 1. Ticket #32823 is not a duplicate of #32628. #32628 was indeed a mixed bag but mostly a feature request including a bugfix. #32823 was an attempt to get the bug fixed ASAP while perhaps discussing the feature request made in #32628 separately. This, apparently, was not understood. 2. I understand that a feature request might be disregarded, but ignoring a bugfix with an offered PR is harder to understand for me. 3. Regarding the original feature request, I am disappointed that it got flagged as wontfix before I even had a chance to make my point and be understood. I later offered a slight rewrite of the autocomplete.js file that implemented the feature (and fixed the bug) in a way that could be accepted by Johannes Maron (not breaking Select2 API mirroring) but got no answer. I understand that Django is a very large project and that you guys are all volunteering to this. I (and my company) am definitely willing to offer developer time to help this project grow. But treating new-coming developers like you did is just discouraging (to say the least), at least for me. So will you please consider at least discussing the issues I raise here? Best regards, Sébastien Gélis -- 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/CANSK4jZ2xD-v07QWKGLURYy-tA%3DW_%3DuxPqsxXWym-55yk7ZKNQ%40mail.gmail.com.
Re: Discussion regarding #32628 and #32823
t organizations who try to > build their "back office" within the admin end up digging themselves into a > bit of a hole with their customizations. Building your own pieces is > normally a better approach when you need a certain level of customization. > > Just yesterday I was advising a client who wanted some different > autocomplete customizations. I also recommended trying django-select2, as > Johannes wrote on the ticket ( > https://code.djangoproject.com/ticket/32628#comment:5 ). > -- 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/b8f6e528-dbd7-4c82-b3f8-4739eb1a4d41n%40googlegroups.com.
Re: Discussion regarding #32628 and #32823
> *The number of lines is not the most important factor. There is no point
in adding a new feature without tests and docs, because without them we
will add a feature only for a single user, i.e. for the reporter. Also, we
cannot add features just because they are not complex ("death by a thousand
cuts"), each of them has a maintenance cost. Moreover, adding new features
to the admin which are not used by admin itself is quite controversial.*
Totally agree with you on that. My point was therefore: let's either
implement this feature fully or, as Adam later suggested, remove the options
parameter.
> *Django's policy for what is maintained and extensible as "public API" is
only those things that have been documented. This is its "deprecation
policy":
https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy
<https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy>
. Since neither the function nor the parameter have been documented, no one
should not rely on them. It's the same for an unused parameter in an
internal Python function. We remove many such parameters in each Django
version without deprecation.*
Thanks for this important clarification. I'll refactor my code to use a
totally custom JS then, and leave this undocumented autocomplete.js alone
for good :-)
> *If anything, your highlighting the parameter has made me think we could
remove it.*
Count me in favor of this + documenting how front-end overrides of
autocomplete are expected to be done (complete override of autocomplete.js
or custom version compatible with AutocompleteJsonView).
Would be happy to push a commit in this direction.
Thanks again to you guys for taking the time to lead me through this!
Sébastien
Le mardi 8 juin 2021 à 17:39:22 UTC+2, Adam Johnson a écrit :
> I'd be happy to suggest longer versions (if technically possible to
>> implement).
>>
>
> At least the documentation for triaging tickets is here:
> https://github.com/django/django/blob/main/docs/internals/contributing/triaging-tickets.txt
>
> .
>
> I do not understand why the $.fn.djangoAdminSelect2 function would accept
>> an options parameter at all then. This options parameter is never used in
>> Django's own code, as far as I can tell.
>>
>
> This looks like an oversight in the original commit to add the function:
> https://github.com/django/django/commit/94cd8efc50c717cd00244f4b2233f971a53b205e
>
> . The parameter has indeed never been used by Django.
>
> Django's policy for what is maintained and extensible as "public API" is
> only those things that have been documented. This is its "deprecation
> policy":
> https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy
>
> . Since neither the function nor the parameter have been documented, no one
> should not rely on them. It's the same for an unused parameter in an
> internal Python function. We remove many such parameters in each Django
> version without deprecation.
>
> If anything, your highlighting the parameter has made me think we could
> remove it.
>
> On Tue, 8 Jun 2021 at 15:55, Mariusz Felisiak
> wrote:
>
>> > Additionally, I do not see how this would add complexity to the code
>> and/or the API. The API would remain strictly the same (
>> $.fn.djangoAdminSelect2(options)) and the code itself needs only an
>> additional ~5 lines.
>>
>> The number of lines is not the most important factor. There is no point
>> in adding a new feature without tests and docs, because without them we
>> will add a feature only for a single user, i.e. for the reporter. Also, we
>> cannot add features just because they are not complex (*"death by a
>> thousand cuts"*), each of them has a maintenance cost. Moreover, adding
>> new features to the admin which are not used by admin itself is quite
>> controversial.
>>
>> My 2 cents.
>>
>> Best,
>> Mariusz
>>
>> --
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/07713c30-7d56-4f34-b802-8e4d3cfc2bc6n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/django-developers/07713c30-7d56-4f34-b802-8e4d3cfc2bc6n%40googlegroups.com?utm_medium=email&utm_source=foote
[Feature Request] In admin the variable has_change_permission in change_form.html should not be used for the breadcrumb menu
In admin when rendering a change form the breadcrumb menu includes a link to the changelist, or only a text. The template’s variable has_change_permission is used to decide which to show. As far as I understand the variable is set in ModelAdmin to has_change_permissions(request, obj) by default, but a user with has_change_permissions(request, obj=None) returning False will get a permission error clicking the link. I propose to take account of the possibility that the implication has_change_permissions(request, obj) is True implies has_change_permissions(request, obj=None) is True is not true. The redirect behaviour in ModelAdmin's response_post_save_add et al. seems to handle this case. My implementation idea is to add another template variable in AdminModel's render_change_form. If this change and implementation is welcomed I can try to create a patch if someone can provide guidance for what to do besides the two one line changes. Greetings -- 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/62d320b1-338c-4e06-9abb-75f97a1a7859%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Performance does not scale when increasing file upload sizes
Story Our application supports many file uploads. In normal circumstances, those files are only a few megabytes to of around 100MB. However, some uploads can be several GB in size (10-15GB and up). I know, that file uploads with such a size can be handled differently, e.g. using a seperate endpoint, allowing slow requests to be served seperately from the application etc. and only to reference those files in a final request. This solution would introduce some other problems regarding house-keeping, non-atomic requests etc, thus I want to ignore this workaround for now. Performance impact: <https://code.djangoproject.com/ticket/33699#Performanceimpact:> The impact can be best observed when uploading a file which is bigger in it's size, e.g. 1GB+. On my maschine it takes the client around 700ms to send the request to the application, but than waits around 1.5s for the final response. Of course, those numbers are dramatically influenced additionally in production by storage speed, file size, webserver (uvicorn/daphne/..), load-balancers etc. But the final take here is, that the server does some additional work after the client finished its request. In a production-like environment the numbers peaks to 4s (send request) and 16s (waiting for response) for the same file size. Uploading a 3GB file, the numbers are 11s and 44s. As you can see, the 44s are very near the default gateway timeout of Nginx and the hard-coded one of AWS load-balancers. As soon as the server needs more than 60s to create the response, the client will get a gateway timeout error. Workflow of file uploads: <https://code.djangoproject.com/ticket/33699#Workflowoffileuploads:> I'm not a Django-dev, so please correct me if I'm wrong. As far as I understand, the uploaded file is processed as the following: Given, that the application is running within an ASGI server, the whole request is received by the ASGIHandler. It's method #read_body creates a SpooledTemporaryFile. This temporary file contains the whole request body, including POST parameters and files. As soon as the request has been received (this is the point the client finished uploading the file) it is than transformed into an ASGIRequest. The ASGIRequest has #_load_post_and_files and #parse_file_upload as methods which parses the body into seperate files. This is done by reading the body (the temporary file) and iterating over them seperated by the POST seperator done by MultiPartParser. The generated chunks are than sent to upload handlers which process those files further on using #receive_data_chunk. The default upload handlers provided by Django will write those files to disc again, depending on their size. Problem <https://code.djangoproject.com/ticket/33699#Problem> The problem here is, that the uploaded file(s) are transformed and written as well as read multiple times. First the whole body is written into a SpooledTemporaryFile which is re-read using streams (LazyStream) just to be written once more by an upload handler. The impact is low if the uploaded file is small, but increases dramatically if the size is increased, the file hits the disc and/or the storage is slow. Optimization / Brainstorming <https://code.djangoproject.com/ticket/33699#OptimizationBrainstorming> Would it be possible to reduce the workflow to a single write call? E.g. if the ASGIHandler already splits the request body into seperate files, it would be possible to just forward the file pointers until the upload handlers needs to be called. Those handlers would be able to either use those files as-is or to re-read them if pre-processing is needed. In a best-case scenario, an user uploads a file whichis created as a temporary file in parallel. As soon as the request has been finished, the file is than moved to its final location (as already implemented by upload handlers by providing #temporary_file_path) The server would not need any time processing the request further on and would be able to sent the response within some milliseconds independent of the file size. The roundtrip time would be reduced by 2/3 and also the gateway timeout would be fixed. Environment <https://code.djangoproject.com/ticket/33699#Environment> We're using Django 4.0.4 with Gunicorn 20.1.0 and Uvicorn 0.17.6. Attachments <https://code.djangoproject.com/ticket/33699#Attachments> I've attached two flame graphs of a file upload which hopfully illustrates this issue. One is using the internal runserver (wsgi) and one of our (stripped) application using gunicorn+uvicorn (asgi) Final notes I'd by happy to get some thoughts and opinions on this issue and if this is even possible to change/implement. Cross-posted from https://code.djangoproject.com/ticket/33699 as ticket has been closed due to wrong place... -- You received this message because you are subscribed to the Google Groups "Django develop
Re: Performance does not scale when increasing file upload sizes
Hi all, I've played around a bit and would like to give you a heads up: WSGI and ASGI have only differences in how they parse incoming requests. As WSGI is synchronous the body is already provided as a ByteIO stream which is set directly on the HTTPRequest (wrapped as a LazyStream). On ASGI the body is sent in chunks. As the base of HTTPRequest - and this includes how to parse the body, POST, FILES etc. - is the same for ASGI and WSGI, those chunks need to be joined together prior to any other processing. to do this, all chunks are currently written into the SpooledTemporaryFile mentioned in my previous post and this file is then provided as a stream to the HTTPRequest. As already written, this workaround to get all chunks into one stream is very slow for requests which are bigger in their size as the temporary file is spooled to disc in the worst case. To workaround this issue, I've tried to delay the reading of the ASGI queue to get the next chunk (called "message" in ASGI) until the HTTPRequest really needs it. As the HTTPRequest/MultiFileParser works on a stream to read and parse its body, the idea is to use the ASGI queue as a stream-like object and to directly read it. This would eliminate the need to create a temporary file as a "proxy". When I was in the process of implementing this interface, I've recognized that the package a2wsgi already handles such use-case: https://github.com/abersheeran/a2wsgi/blob/master/a2wsgi/wsgi.py I've added a2wsgi as a dependency and change the ASGI handler a little bit. The changes can be reviewed on my fork: https://github.com/Flauschbaellchen/django/commit/006bf2d5c0b82092524ee9b65ef919637165ee01 Timings: In my test environment, the timing went from 4s (sending)/16s (waiting) to 6s/5s. Sending is a bit slower. This is because prior to the change the chunks have been read directly into the temporary file and now the parser is doing its business between reading new chunks. However, those chunks are directly parsed and feed into the upload handlers which dramatically improves the performance on the server side. Using gunicorn+uvicorn the waiting time went down to ~600ms. I don't know why runserver/daphne is so slow. I'll check this within the next days. I've attached a new flame graph representing my changes. The right-most block can be ignored - this is already the next GET request of the admin panel after saving the object. What's next? I would appreciate any feedback on my changes. Is this the right direction? What about the newly introduced dependency? - It would also be possible to implement/copy the code on the Django side to eliminate this dependency. However, on my opinion, doing things twice is never a good idea... Can anyone test against other environments/ASGI servers? Maybe I've overlooked some edge cases. The current changes depends on the version 4.0.4 of Django as on the main branch small changes happend to the ASGI handler. I'll rebase my changes prior to submitting a PR. With kind regards :) On Wednesday, May 11, 2022 at 7:47:10 PM UTC+2 Adam Johnson wrote: > Ferran - No, this is the right place. Noxx is suggesting a change to > Django. > > Noxx - it seems reasonable to improve Django here. You mentioned ASGI - > did you check what the WSGI paths do? It may be that the newer ASGI code is > simply less optimal. > > Would it be possible to reduce the workflow to a single write call? >> > > This is indeed the question. Could you investigate further and perhaps > come up with a patch? You're likely "the world expert" on this part of > Django at this point, after all the profiling you've done. > > > On Wed, May 11, 2022 at 5:44 PM Ferran Jovell wrote: > >> This is still the wrong place. Try django-users mailing list. >> >> El dc., 11 de maig 2022, 17:53, 'Noxx' via Django developers >> (Contributions to Django itself) va >> escriure: >> >>> Story >>> >>> Our application supports many file uploads. >>> In normal circumstances, those files are only a few megabytes to of >>> around 100MB. >>> However, some uploads can be several GB in size (10-15GB and up). >>> >>> I know, that file uploads with such a size can be handled differently, >>> e.g. using a seperate endpoint, allowing slow requests to be served >>> seperately from the application etc. >>> and only to reference those files in a final request. >>> This solution would introduce some other problems regarding >>> house-keeping, non-atomic requests etc, thus I want to ignore this >>> workaround for now. >>> Performance impact: >>> <https://code.djangoproject.com/ticket/33699#Performanceimpact:> >>> >>
Re: Performance does not scale when increasing file upload sizes
Hi Carlton, thanks for your response. I've opened up a PR: https://github.com/django/django/pull/15704 I've decided to moved the "ASGIStream" wrapper code into the Django code and get rid of the dependency as it is only a small part of it. My version of the code was nearly the same as the one from a2wsgi so I used the latter one (I think that their version is a bit more battle-proofed) and added the http.disconnect exception which was missing. However, I do not know what would be an appropriate way forward: Leave it as it is, add a "thank you" comment that the code was more-or-less taken from/based on a2wsgi and/or that improvements to ASGIStream should be checked if they also apply to a2wsgi? However, we can further discuss the changes within the PR if you want. Kind regards, Noxx On Tuesday, May 17, 2022 at 7:20:18 PM UTC+2 carlton...@gmail.com wrote: > Hi Noxx. > > This is interesting, thanks for the write-up. > > As a bit of history, initially ASGIRequests would read the whole body into > memory, which was fine for an initial version, but led quickly enough to > resource concerns. Andrew followed up with the SpooledTemporaryFile > approach, as a nice next-step improvement on that. There **was** at the > time some initial work on wrapping the receive queue to consume the body > on-demand, but with the temp-file solution in hand that never got pushed > through. I can very well imagine folks in ASGI-land have had time to get > that right now. (So exciting to look at!) > > I'd very much want to dig into a dependency before deciding to take one > on. I suspect it's not **that** complex, so it's likely something we'd want > to re-implement to fit our needs exactly. (But we can see on review...) > > Please do open a PR when you're ready. > > Kind regards, > Carlton > > On Tue, 17 May 2022 at 15:20, 'Noxx' via Django developers (Contributions > to Django itself) wrote: > >> Hi all, >> >> I've played around a bit and would like to give you a heads up: >> >> WSGI and ASGI have only differences in how they parse incoming requests. >> As WSGI is synchronous the body is already provided as a ByteIO stream >> which is set directly on the HTTPRequest (wrapped as a LazyStream). >> >> On ASGI the body is sent in chunks. As the base of HTTPRequest - and this >> includes how to parse the body, POST, FILES etc. - is the same for ASGI and >> WSGI, those chunks need to be joined together prior to any other processing. >> to do this, all chunks are currently written into the >> SpooledTemporaryFile mentioned in my previous post and this file is then >> provided as a stream to the HTTPRequest. >> As already written, this workaround to get all chunks into one stream is >> very slow for requests which are bigger in their size as the temporary file >> is spooled to disc in the worst case. >> >> To workaround this issue, I've tried to delay the reading of the ASGI >> queue to get the next chunk (called "message" in ASGI) until the >> HTTPRequest really needs it. >> As the HTTPRequest/MultiFileParser works on a stream to read and parse >> its body, the idea is to use the ASGI queue as a stream-like object and to >> directly read it. >> This would eliminate the need to create a temporary file as a "proxy". >> >> When I was in the process of implementing this interface, I've recognized >> that the package a2wsgi already handles such use-case: >> https://github.com/abersheeran/a2wsgi/blob/master/a2wsgi/wsgi.py >> >> I've added a2wsgi as a dependency and change the ASGI handler a little >> bit. >> The changes can be reviewed on my fork: >> https://github.com/Flauschbaellchen/django/commit/006bf2d5c0b82092524ee9b65ef919637165ee01 >> >> Timings: >> In my test environment, the timing went from 4s (sending)/16s (waiting) >> to 6s/5s. >> Sending is a bit slower. This is because prior to the change the chunks >> have been read directly into the temporary file and now the parser is doing >> its business between reading new chunks. >> However, those chunks are directly parsed and feed into the upload >> handlers which dramatically improves the performance on the server side. >> Using gunicorn+uvicorn the waiting time went down to ~600ms. I don't know >> why runserver/daphne is so slow. I'll check this within the next days. >> >> I've attached a new flame graph representing my changes. >> The right-most block can be ignored - this is already the next GET >> request of the admin panel after saving the object. >&
Re: Generated Field
t;
> *if self.db_collation is not None:*
>
> *kwargs['db_collation'] = self.db_collation*
>
> *return name, path, args, kwargs*
>
>
>
> *class GeneratedFieldQuerysetMixin:*
>
> *"""*
>
> *Must be added to queryset classes*
>
> *"""*
>
>
> *def _insert(self, objs, fields, *args, **kwargs):*
>
> *if getattr(self.model, '_generated_fields', None) and fields:*
>
> *# Don't include generated fields when performing a
> `model.objects.bulk_create()`*
>
> *fields = [f for f in fields if f not in
> self.model._generated_fields()]*
>
>
> *return super()._insert(objs, fields, *args, **kwargs)*
>
>
>
> *class GeneratedFieldModelMixin:*
>
> *"""*
>
> *Must be added to model class*
>
> *"""*
>
>
> *def _generated_fields(cls) -> list[Field]:*
>
>
> *"""*
>
> *:return all fields of the model that are generated*
>
> *"""*
>
>
> *return [*
>
> *f*
>
> *for f in cls._meta.fields*
>
> *if isinstance(f, GeneratedField)*
>
> *]*
>
>
> * def _do_insert(self, manager, using, fields, *args, **kwargs):*
>
> *generated_fields = self._generated_fields()*
>
> *if generated_fields and fields:*
>
> *# Don't include generated fields when performing a `save()`
> or `create()`*
>
> *fields = [f for f in fields if f not in generated_fields]*
>
>
> *return super()._do_insert(manager, using, fields, *args,
> **kwargs)*
>
>
> *def _do_update(self, base_qs, using, pk_val, values, *args,
> **kwargs):*
>
> *generated_fields = self._generated_fields()*
>
> *if generated_fields and values:*
>
> *# Don't include generated fields when performing an
> `update()`*
>
> *values = [v for v in values if v[0] not in generated_fields]*
>
>
> *return super()._do_update(base_qs, using, pk_val, values, *args,
> **kwargs)*
>
>
>
> On Wednesday, April 13, 2022 at 2:38:49 p.m. UTC-6 dans...@gmail.com
> wrote:
>
>> +1
>>
>> On Wed, Apr 13, 2022 at 7:01 AM 'Adam Johnson' via Django developers
>> (Contributions to Django itself) wrote:
>>
>>> I'd be interested in seeing this. Generated columns are a useful SQL
>>> feature that are missing from Django.
>>>
>>> Nice initial research on backend coverage - it looks like they're widely
>>> supported.
>>>
>>> Some ideas...
>>>
>>> Is it necessary to take a base field? Can we not determine the output
>>> field type for some kinds of expression? e.g. F("some_integer_field") + 1
>>> can be assumed to have output field type IntegerField.
>>>
>>> Would it be worth blocking assignment to the field? Allowing
>>> "model.generated_field = ..." would at least be misleading. (This could be
>>> done with a special descriptor.)
>>>
>>> Good luck!
>>>
>>> On Wed, Apr 13, 2022 at 11:25 AM Paolo Melchiorre
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I am at PyCon DE 2022 in Berlin with Markus and I shared with him this
>>>> idea that I have been thinking about for a few months, given his
>>>> interest I also share it with you.
>>>>
>>>> I figured we could add in Django a "GeneratedField" which accepts a
>>>> "base_field" attribute in a similar way to "ArrayField" and then an
>>>> expression to generate a value for the field.
>>>>
>>>> For example this model:
>>>>
>>>> class Album(models.Model):
>>>>...
>>>>title = models.CharField(max_length=120)
>>>>search = GeneratedField(
>>>> SearchVectorField(),
>>>> F('title')
>>>>)
>>>>
>>>> would generate an SQL code like this in PostgreSQL:
>>>>
>>>> CREATE TABLE album (
>>>> ...
>>>> title char(120),
>>>> search tsvector GENERATED ALWAYS AS title STORED
>>>> );
>>>>
>>>> I found some documentation for different database backend about
>>>> generated column (or similar names)
>>>>
>>>>
Request for Guidance
Hello sir, i am Gairick a second year MCA student and want to contribute ,can you please point to me some resources by reading i can contribute to codebase and learn new technologies and please share me the guide for installation Regards,Gairick Virus-free.www.avast.com DisclaimerThis email is governed by the Disclaimer Terms of somaiya.edu which may be viewed at https://www.somaiya.edu/en/email-disclaimerFinally, please do not print this email unless it is necessary. Every unprinted email helps the environment. -- 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/B95C3F85-61CC-4644-871F-E00363318A22%40hxcore.ol.
Re: QuerySet.iterator together with prefetch_related because of chunk_size
t;> would also perform P * C extra queries where P is the number of >>>>>> prefetches >>>>>> requested through prefetch_related() and C the number of chunks the >>>>>> results >>>>>> contains. This is non negligible IMO. >>>>>> >>>>>> What I'd be in favor off is raising an exception on >>>>>> prefetch_related(*prefetches).iterator() in the next release at least to >>>>>> allow users using this pattern to adjust their code and then ship the >>>>>> optimization with all the warnings related to the interactions between >>>>>> prefetch_related(*prefetches) and iterator(chunk_size) in the next one. >>>>>> >>>>>> I'm not completely completely against skipping the exception release >>>>>> phase entirely given there might be users out there accessing attributes >>>>>> expected to be prefetched on iterated instances and inadvertently >>>>>> performing tons of queries but the exception phase just feels safer >>>>>> given >>>>>> iterator() is usually used in memory constrained contexts. >>>>>> >>>>>> Simon >>>>>> >>>>>> Le vendredi 26 octobre 2018 19:27:55 UTC-4, Josh Smeaton a écrit : >>>>>>> >>>>>>> I tend to agree with Tobi. Prefetching silently not working on >>>>>>> iterator can be quite confusing, unless you have a good understanding >>>>>>> of >>>>>>> both APIs. It might be possible to do what you're asking, but it'd mean >>>>>>> that django is now actually caching the result when it explicitly says >>>>>>> it >>>>>>> isn't - even if the result is a much smaller moving cache. Prefetching >>>>>>> chunk_size results per chunk is unlikely to make a material difference >>>>>>> to >>>>>>> memory usage. Users are usually concerned about the entire result set >>>>>>> of >>>>>>> the primary table. >>>>>>> >>>>>>> I don't know if you can change the API to make these suggested >>>>>>> changes without also impacting how we iterate over result sets - but >>>>>>> I'd be >>>>>>> interested in seeing a proof of concept at the very least. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Monday, 15 October 2018 20:41:13 UTC+11, tobias@truffls.com >>>>>>> wrote: >>>>>>>> >>>>>>>> Thank you for your feedback. I would like to answer some statements >>>>>>>> to either convince you or make it more clear, where my idea stems from: >>>>>>>> >>>>>>>> The fundamental reason why iterator() cannot be used with >>>>>>>>> prefetch_related() is that the latter requires a set of model >>>>>>>>> instance to >>>>>>>>> be materialized to work appropriately which chunk_size doesn't >>>>>>>>> control at >>>>>>>>> all. >>>>>>>>> In other words chunk_size only controls how many rows should be >>>>>>>>> fetched from the database cursor and kept into memory at a time. Even >>>>>>>>> when >>>>>>>>> this parameter is used, iterator() will only materialize a single >>>>>>>>> model >>>>>>>>> instance per yield. >>>>>>>>> >>>>>>>> >>>>>>>> It should be easily possible to change the involved code of >>>>>>>> ModelIterable to materialize the retrieved rows in batches. After >>>>>>>> materializing the batch / chunk, it could do the prefetching. >>>>>>>> >>>>>>>> >>>>>>>>> Given that iterator() always ignored prefetch related lookups >>>>>>>>> instead of erroring out when they were specified make me feel like >>>>>>>>> turning >>>>>>>>> such a feature on by default could be problematic as it could balloon >>>>>>>>> the >>>>>>>>> memory usage which is the main reason why iterator is useful anyway. >>>>>>>>> >>>>>>>> >>>>>>>> I would argue, that users who thoughtlessly applied prefetching >>>>>>>> together with iterator now actually get, what they thought of: less DB >>>>>>>> query round trips traded against a little more memory usage. >>>>>>>> >>>>>>>> Best, >>>>>>>> Tobi >>>>>>>> >>>>>>> -- >>>>> 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-develop...@googlegroups.com. >>>>> To post to this group, send email to django-d...@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/1f5d8b5a-8c7c-4575-b904-adfaa9d1900d%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/django-developers/1f5d8b5a-8c7c-4575-b904-adfaa9d1900d%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> -- >>>> Adam >>>> >>> -- >>> 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-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@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/7cd3d351-675b-4e43-9d17-e18f28a2b159%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/7cd3d351-675b-4e43-9d17-e18f28a2b159%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> -- >> Adam >> > -- 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/03fa0616-d890-4fbf-9c4a-592d20ff0a8a%40googlegroups.com.
Paid Contributions for specific feature in Django
Hi All, I am not sure if this is the place to ask this question, so sorry in advance, but I am looking to pay for a feature request. I would like for someone to build a Django DB adapter for Snowflake DB. https://www.snowflake.com/ It would be happy if it was a part of Django core or a separate package. Either way, it would be 100% open source after completion. Is there any process for this type of thing? If there isn't, is there anyone on here interested in this type of work? Best, Taylor -- 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/d2a082af-c014-47d9-909f-87298a2e117bn%40googlegroups.com.
Re: Snowflake db backend
Hey Everyone, Sorry to open up an old thread. Tim - were you ever able to open source your Snowflake backend? We would love to use it and even devote resources (developers or funding for contractors) to improving it and getting the tests passing. At Cedar, we were planning on creating our own Snowflake backend, but it would be great to not duplicate work here. What are your thoughts? Best, Taylor On Wednesday, January 27, 2021 at 1:08:13 AM UTC-8 f.apo...@gmail.com wrote: > Hi Scott, > > Thank you for your response, this is very helpful. > > On Tuesday, January 26, 2021 at 11:38:18 PM UTC+1 foug...@apps.disney.com > wrote: > >> Snowflake does not support lastrowid. So, we grab the last ID inserted >> with a 'SELECT MAX(pk_name) FROM table_name'. This is obviously prone to >> failure. Assigning an ID during the INSERT would provide similar results >> on all backends. >> > > U, the 'SELECT MAX()' is not going to fly well, you are right. > Assigning an ID during INSERT has it's own problems. In postgresql it would > be possible because you could just select the next value from the created > sequence (more or less), but with IDENTITY columns this might get harder. I > do not think there is a sensible way to do this in MySQL at all. While > lastrowid support is a nice to have, Django should work (mostly?) without > it: > https://github.com/django/django/blob/464a4c0c59277056b5d3c1132ac1b4c6085aee08/django/db/models/sql/compiler.py#L1372-L1387 > > -- the requirement here is that your database is at least able to return > values after insert. From the looks of it, it does not I think? Or > differently put: Which ways does snowflake offer to get an ID? Solely by > providing it directly into insert? > > The feature flag `supports_transactions` really means >> `supports_nested_transactions`. Snowflake supports a single level of >> transaction, BEGIN + (ROLLBACK|COMMIT). Multiple BEGINS contribute to the >> current (only) transaction. Since I have to set this flag to False, no >> transactions are used, even ones that are supported and testing grinds to a >> crawl with all of the table truncations and repopulation. Since Django >> *normally* operates in auto-commit mode, this isn't a huge deal. >> Snowflake also doesn't support save points, but the feature flag seems to >> do what is expected when disabled. >> > > Hu, which database support nested BEGIN? As far as I am aware Django does > never nest BEGINs -- do you have an example for me? I'd very much like to > fix this. From a quick glance at the code we only start a transaction if we > are not already in one: > https://github.com/django/django/blob/master/django/db/transaction.py#L196-L208 > > Snowflake does not support column references without a FROM or JOIN >> clause. I've only encountered this used in the unit tests. >> > > Ok, see below. > > I've been able to work around most of the function differences by adding >> as_snowflake methods to the appropriate classes. There are a few cases >> like JSON_OBJECT that don't translate well, which work, but not entirely as >> expected. >> > > Perfect, this sounds as if our extension system works as intended in this > area. > > A search for 'connection.vendor == ' in the core code shows one example of >> where core backends are given privileged access to core Django inner >> workings that 3rd party backends don't. >> > > We have been working to get rid of those: > https://github.com/django/django/commit/275dd4ebbabbbe758c7219a3d666953d5a7b072f#diff-69f332030b6f25f8f4d95842548d847139ee2cc163aef18f1c8d83b90f3f9e5f > > -- This is solely in 3.2, but Tim can suggest a workaround for earlier > versions (he was doing something similar in his cockroachdb tests before > 3.2). > > Please take these comments as observations, not complaints. I understand >> project evolution and the resistance to change something that doesn't seem >> broken. Maybe keep some of these thoughts in mind when a change is made to >> the core backends or the compiler and consider how other backends will need >> to implement that new feature. >> > > No offense taken at all. If somehow possible I'd like to encourage you to > work with us on your pain points. I think at least some of those are > addressed or at least addressable. I am happy to offer code and fixes, but > I'll need a few more details especially wrt transaction handling. > > Cheers, > Florian > -- 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/03abf31b-75db-433e-9d35-ead6fefff5a4n%40googlegroups.com.
Re: Snowflake db backend
Sorry, I meant to write Scott, not Tim. I shouldn't write emails late at night. - Taylor On Tuesday, April 20, 2021 at 10:29:46 PM UTC-7 Taylor wrote: > Hey Everyone, > > Sorry to open up an old thread. > > Tim - were you ever able to open source your Snowflake backend? We would > love to use it and even devote resources (developers or funding for > contractors) to improving it and getting the tests passing. At Cedar, we > were planning on creating our own Snowflake backend, but it would be great > to not duplicate work here. What are your thoughts? > > Best, > Taylor > > On Wednesday, January 27, 2021 at 1:08:13 AM UTC-8 f.apo...@gmail.com > wrote: > >> Hi Scott, >> >> Thank you for your response, this is very helpful. >> >> On Tuesday, January 26, 2021 at 11:38:18 PM UTC+1 foug...@apps.disney.com >> wrote: >> >>> Snowflake does not support lastrowid. So, we grab the last ID inserted >>> with a 'SELECT MAX(pk_name) FROM table_name'. This is obviously prone to >>> failure. Assigning an ID during the INSERT would provide similar results >>> on all backends. >>> >> >> U, the 'SELECT MAX()' is not going to fly well, you are right. >> Assigning an ID during INSERT has it's own problems. In postgresql it would >> be possible because you could just select the next value from the created >> sequence (more or less), but with IDENTITY columns this might get harder. I >> do not think there is a sensible way to do this in MySQL at all. While >> lastrowid support is a nice to have, Django should work (mostly?) without >> it: >> https://github.com/django/django/blob/464a4c0c59277056b5d3c1132ac1b4c6085aee08/django/db/models/sql/compiler.py#L1372-L1387 >> >> -- the requirement here is that your database is at least able to return >> values after insert. From the looks of it, it does not I think? Or >> differently put: Which ways does snowflake offer to get an ID? Solely by >> providing it directly into insert? >> >> The feature flag `supports_transactions` really means >>> `supports_nested_transactions`. Snowflake supports a single level of >>> transaction, BEGIN + (ROLLBACK|COMMIT). Multiple BEGINS contribute to the >>> current (only) transaction. Since I have to set this flag to False, no >>> transactions are used, even ones that are supported and testing grinds to a >>> crawl with all of the table truncations and repopulation. Since Django >>> *normally* operates in auto-commit mode, this isn't a huge deal. >>> Snowflake also doesn't support save points, but the feature flag seems to >>> do what is expected when disabled. >>> >> >> Hu, which database support nested BEGIN? As far as I am aware Django does >> never nest BEGINs -- do you have an example for me? I'd very much like to >> fix this. From a quick glance at the code we only start a transaction if we >> are not already in one: >> https://github.com/django/django/blob/master/django/db/transaction.py#L196-L208 >> >> Snowflake does not support column references without a FROM or JOIN >>> clause. I've only encountered this used in the unit tests. >>> >> >> Ok, see below. >> >> I've been able to work around most of the function differences by adding >>> as_snowflake methods to the appropriate classes. There are a few cases >>> like JSON_OBJECT that don't translate well, which work, but not entirely as >>> expected. >>> >> >> Perfect, this sounds as if our extension system works as intended in this >> area. >> >> A search for 'connection.vendor == ' in the core code shows one example >>> of where core backends are given privileged access to core Django inner >>> workings that 3rd party backends don't. >>> >> >> We have been working to get rid of those: >> https://github.com/django/django/commit/275dd4ebbabbbe758c7219a3d666953d5a7b072f#diff-69f332030b6f25f8f4d95842548d847139ee2cc163aef18f1c8d83b90f3f9e5f >> >> -- This is solely in 3.2, but Tim can suggest a workaround for earlier >> versions (he was doing something similar in his cockroachdb tests before >> 3.2). >> >> Please take these comments as observations, not complaints. I understand >>> project evolution and the resistance to change something that doesn't seem >>> broken. Maybe keep some of these thoughts in mind when a change is made to >>> the core backends or the compiler and consi
SafeExceptionReporterFilter should obfuscate all variables in every stack frame below a function decorated with sensitive_variables
SafeExceptionReporterFilter obfuscates variables in the function decorated
with sensitive_variables, but it does not obfuscate variables lower in the
call stack, which could result in sensitive data being leaked in exception
reports.
For instance:
@sensitive_variables('sensitive')
def decorated_function():
sensitive = 'something sensitive'
undecorated_function(sensitive)
def undecorated_function(var):
raise Exception()
In this code, the "sensitive" variable will be obfuscated in
the decorated_function stack frame, but "var" in the undecorated_function
stack frame will not, resulting in the sensitive data being leaked in the
report. If we wrote undecorated_function, then we can just decorate the
function ourselves, but if it's from a third-party package, we are unable
to decorate it.
The solution here is to obfuscate _all_ variables in all stack frames below
a function decorated with sensitive_variables, since these functions can do
arbitrary things with the sensitive data. I've written a custom
SafeExceptionReporterFilter that does this for the company I work for, and
I think it would be a good behavior to adopt in core Django.
Any thoughts or concerns with this approach?
--
This message, including any attachments, is a PRIVATE communication,
which may contain confidential, legally privileged, and/or proprietary
information. If you are not the intended recipient, you are hereby
notified that any dissemination, disclosure, copying, distribution or use
of the information contained in or attached to this message is strictly
prohibited. Please notify the sender of the delivery error by replying to
this message, and then permanently delete it from your system. Unless
explicitly stated to the contrary, nothing contained in this message shall
constitute an offer to buy or sell, or a solicitation of an offer to buy or
sell, any security, property interest or other asset, nor shall it
constitute a binding obligation of any kind, an official confirmation of
any transaction or an official statement of Cadre.
Cadre may monitor,
review and retain email communications traveling through its networks or
systems, AND CADRE IS NOT OBLIGATED TO RESTRICT THE USE OR DISCLOSURE OF
ANY INFORMATION SENT TO IT BY YOU VIA E-MAIL COMMUNICATION.
--
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/7376ab0c-530c-42d8-9cfb-6c829af21098%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: PostgreSQL aggregation and views through unmanaged models
Hello, the fix for https://code.djangoproject.com/ticket/27241 caused significant performance drop for my project, because it pretty much prevents posgresql from using indexes on the particular query. I use unmanaged tables because Django is used to display data from another project's database, so it has just read-only access to the database and I don't want to create any migrations for it. Another solution I came up while writing this post would be to replace the > feature flag by a callable that takes a model as a single parameter and > returns > whether or not the optimization can be performed against it. The default > implementation would return `mode._meta.managed` but it would make it > easier for > users affected by this to override in order to opt-in or out based on their > application logic. > This would be perfect for my (arguably niche) use case. Should I try to prepare a patch? On Monday, May 22, 2017 at 5:05:38 AM UTC+2, charettes wrote: > > Hello fellow developers, > > As some of you may know PostgreSQL 9.1 added support for GROUP'ing BY > selected table primary keys[0] only. Five years ago it was reported[1] that > Django could rely on this feature to speed up aggregation on models backed > up by tables with either many fields or a few large ones. > > Being affected by this slow down myself I decided to dive into the ORM > internals > and managed to get a patch that made it in 1.9[2] thanks to Anssi's and > Josh's > review[3]. > > One subtle thing I didn't know back in the time is that PostgreSQL query > planner > isn't able to introspect database views columns' functional dependency > like it > does with tables and thus prevents the primary key GROUP'ing optimization > from > being used. > > While Django doesn't support database views officially it documents that > unmanaged models can be used to query them[4] and thereby perform > aggregation on > them and generating an invalid query. > > This was initially reported as a crashing bug 9 months ago[5] and the > consensus > at this time was that it was an esoteric edge case since there was few > reports > of breakages and it went off my radar. Fast-forward to a month ago, this is > reported again[6] and it takes the reporter quite a lot of effort to > determine > the origin of the issue, pushing me to come up with a solution as I > introduced > this behavior. > > Before Claude makes me realize this is a duplicate of the former report > (which I > completely forgot about in the mean time) I implement a patch and commit > it once > it's reviewed [7]. > > When I closed the initial ticket as "fixed" the reporter brought to my > attention > that this was now introducing a performance regression for unmanaged models > relying on aggregation and that we should document how to disable this > optimization by creating a backend subclass as a workaround instead. > > In my opinion the current situation is as follow. The optimization > introduced a > break in backward compatibility in 1.9 as we've always documented that > database > views could be queried against using unmanaged models. If this issue had > been > discovered during the 1.9 release cycle it would have been eligible for a > backport because it was a bug in a newly introduced feature. Turning this > optimization off for unmanaged models by assuming they could be views is > only > going to degrade performance of queries using unmanaged models to perform > aggregation on tables with either a large number of columns or large > columns > using PostgreSQL. > > Therefore I'd favor we keep the current adjustment in the master branch as > it > restores backward compatibility but I don't have strong feelings about > reverting > it either if it's deemed inappropriate. > > Another solution I came up while writing this post would be to replace the > feature flag by a callable that takes a model as a single parameter and > returns > whether or not the optimization can be performed against it. The default > implementation would return `mode._meta.managed` but it would make it > easier for > users affected by this to override in order to opt-in or out based on their > application logic. > > Thank you for your time, > Simon > > [0] https://www.postgresql.org/docs/9.1/static/sql-select.html#SQL-GROUPBY > [1] https://code.djangoproject.com/ticket/19259 > [2] > https://github.com/django/django/commit/dc27f3ee0c3eb9bb17d6cb764788eeaf73a371d7 > [3] https://github.com/django/django/pull/4397 > [4] https://docs.djangoproject.com/en/1.11/ref/models/options/#managed > [5] https://code.djangoproject.com/ti
Re: Standalone is_safe_url() function
Hi Markus, Well, adding new requirements for every function might be not a scalable approach, but if some stuff in django important for security was separated into a sub-project it could allow more people to patch their projects more easily. From what I've seen in various projects I worked in, far too many folks don't update django (and other deps) often enough because their fear that something will break (and it often does when custom code depending on django internals is involved), keeping some parts of the django codebase in a separate but official package could make it easier for many projects to update just it without worrying, provided that package's api is absolutely stable and backward-compatible. People who run unsupported versions of django (I don't approve but it's a reality we have to deal with) could also benefit from it as they can update the package regardless of which version of django itself they use. The major downsides, it seems to me, are that people might get even sloppier with updating django if they think that security sub-package is enough to stay safe (it should be made clear that it's not) and that it adds an additional dependency (but I think it's ok as long as it's just one and its purpose and contents is obvious). Also it would be hard to decide what to leave in django and what to separate. tl;dr what I'm saying is I'm not against moving it from django to a separate package django will depend on, but I'd prefer it having a broader goal than one function, however important. Also, I tried to look up documentation for `is_safe_url()` and failed. Is there any particular reason why it's not documented? You can see seven other things in https://docs.djangoproject.com/en/2.1/ref/utils/#module-django.utils.http but not a single mention of is_safe_url... Ivan. On Wednesday, October 10, 2018 at 1:06:46 PM UTC+3, Markus Holtermann wrote: > > Hi all, > > Django provides a function `django.utils.is_safe_url()` to ensure that a > given URL (absolute or relative) is safe to redirect to. I needed that > functionality on another project that doesn't use Django at all. I thus > built a standalone is-safe-url Python package that can be installed from > PyPI and exposes exactly that functionality: > > $ pip install is-safe-url > Collecting is-safe-url > Downloading https://files.pythonhosted.org/packages/7a/c3 > > /40c363bc4c3d0ddcda3489239ba64752b8c18cb6493e058f8f1b73154925/is_safe_url-1.0-py3-none-any.whl > > > Installing collected packages: is-safe-url > Successfully installed is-safe-url-1.0 > > The code is available on GitLab: https://gitlab.com/MarkusH/is_safe_url > > I'd love to get some feedback on a couple of things: > > - As Django is published under the BSD-3 clause license, the standalone > package is published under the same license. I'd love some feedback if the > package adheres to the required references and naming of the source. > > - I added a note that security issues should be reported privately to the > Django security team at secu...@djangoproject.com or me > personally (I'm a member of the security team and could forward the report > accordingly). Are there suggestions how the statement in the README could > be made more clear? > > - The package is available for Python 2.7, 3.4, 3.5, 3.6, and 3.7. Should > I keep 2.7 or drop it? I know some people are still on 2.7 and 2.7 is still > supported for another 2 years. > > - How would security releases work? When there's a security report against > Django's built-in is_safe_url(), this package would need to be released as > well. > > - Jannis Leidel raised a valid concern about abandonment of this or > similar packages (thanks!): "I'm mostly worried about abandonment of > packages (from experience) that makes maintenance of sec infrastructure > brittle." — https://twitter.com/jezdez/status/1049955307558981634 > > I want to approach the latter concern about abandonment upfront. But I > don't have a clear answer or solution to it yet. > > - Would it be useful to have this package under the Django GitHub org? > - If so, should Django possibly depend on that package by itself? Given > how often Django had security releases because of issues in `is_safe_url()` > releasing a smaller package and not the full Django package could possibly > be beneficial. > - Does somebody from the security team want or should be another > maintainer? > > Thanks for reading. > > Markus > -- 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 re
Feature request: get user by session key
(Hello, the Django documentation says that I should send feature requests to the django-developers mailing list, so I send it here.) I have a need to get a user object using a known session key without an HTTP request. After reading the Django code, I did not find a clean way to do this. Django has the "get_user" function that requires a request object. But it actually uses only "request.session" and nothing else. So I suggest refactoring it something like this: # https://github.com/django/django/blob/master/django/contrib/auth/__init__.py def _get_user_session_key(session): return get_user_model()._meta.pk.to_python(session[SESSION_KEY]) def get_user(request): return get_user_by_session(request.session) def get_user_by_session_key(session_key): SessionStore = import_module(settings.SESSION_ENGINE).SessionStore return get_user_by_session(SessionStore(session_key)) def get_user_by_session(session): from .models import AnonymousUser user = None try: user_id = _get_user_session_key(session) backend_path = session[BACKEND_SESSION_KEY] except KeyError: pass else: ... # the rest of the code return user or AnonymousUser() Note that Django Channels has similar code so the "get_user_by_session" function can help to deduplicate it: https://github.com/django/channels/tree/master/channels/auth.py#L23 -- 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/858abfe1-42b9-185b-e69c-c23d6058e762%40andreymal.org.
Re: Feature request: get user by session key
The page you referred to says: >First request the feature on the django-developers <https://docs.djangoproject.com/en/dev/internals/mailing-lists/#django-developers-mailing-list> list, not in the ticket tracker. That's why I'm here ¯\_(ツ)_/¯ About my case — in general, I want to make a websocket server. Django Channels is too complicated and I don't want to use it for my case; instead, I want to make a very stupid and primitive server (without consumers, routers, channel layers and other scary words; less than 0.5k lines of code). But I still need to authenticate the user, and I want to do exactly what Channels does — get the user model instance for current websocket scope. Now, to prevent code duplication, I have to do something like this: def get_session(self): SessionStore = importlib.import_module(settings.SESSION_ENGINE).SessionStore # self.session_key is loaded from websocket cookies return SessionStore(self.session_key) def get_user_model(self): from django.contrib.auth import get_user from django.http.request import HttpRequest request = HttpRequest() request.session = self.get_session() return get_user(request) But this is obviously ugly. But creating a copy of the "get_user" function and modifying it to fit my needs is even worse. The "get_user_by_session_key" functionI propose can dramatically simplify this code and increase reliability. The same applies to Channels that can get rid of its own copy of the "get_user" function. I expect you'll say "just use Channels and don't be an idiot", but I think this small refactoring will be good anyway, even for Channels. I don't quite understand what you mean by saying "isn't the only thing that would need changing"; as of today, I have not noticed any problems when working with the session without a real request. (I know that it’s not very safe to work with the ORM in async code, but don't worry, I took care of this.) 26.07.2019 19:39, Adam Johnson пишет: > Hey, > > Welcome to the mailing list. This is probably a little low-level as a > feature request here. I think it is better submitted as a ticket as > per > https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-features/ > :) > Where on the docs did you read about django-developers? > > As for your suggested feature - could you talk about your use case a > little more? If Django is going to support sessions not attached to > requests, it's likely this isn't the only thing that would need > changing. And as you've seen in the source, the function you want > right now is only one line (get_user_session_key). > > Thanks, > > Adam > > On Thu, 25 Jul 2019 at 14:09, 'andreymal' via Django developers > (Contributions to Django itself) <mailto:django-developers@googlegroups.com>> wrote: > > (Hello, the Django documentation says that I should send feature > requests to the django-developers mailing list, so I send it here.) > > I have a need to get a user object using a known session key > without an > HTTP request. After reading the Django code, I did not find a > clean way > to do this. > > Django has the "get_user" function that requires a request object. But > it actually uses only "request.session" and nothing else. So I suggest > refactoring it something like this: > > # > > https://github.com/django/django/blob/master/django/contrib/auth/__init__.py > def _get_user_session_key(session): > return get_user_model()._meta.pk.to_python(session[SESSION_KEY]) > > def get_user(request): > return get_user_by_session(request.session) > > def get_user_by_session_key(session_key): > SessionStore = import_module(settings.SESSION_ENGINE).SessionStore > return get_user_by_session(SessionStore(session_key)) > > def get_user_by_session(session): > from .models import AnonymousUser > user = None > try: > user_id = _get_user_session_key(session) > backend_path = session[BACKEND_SESSION_KEY] > except KeyError: > pass > else: > ... # the rest of the code > return user or AnonymousUser() > > Note that Django Channels has similar code so the > "get_user_by_session" > function can help to deduplicate it: > https://github.com/django/channels/tree/master/channels/auth.py#L23 > > -- > You received this message because you are subscribed to the Google > Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving e
Add ability to choose a different secret for PasswordResetToken
Hi everybody, I have two sites in my project. One is for internal use to add members of our club to our database, one is a self-service page for our members. On registration of a member using our internal site, I want to send a password reset link to the member for easy registration to our self-service page. Since the two sites run on different servers and different SECRET_KEYs, I need to specify a different secret for the token generated with our internal site to work on the self-service page. I managed to do so by overwriting the method _make_token_with_timestamp of PasswordResetToken, however, I think this is quite an ugly solution. How would you think about the secret being an attribute of the PasswordResetToken class, which is then passed to salted_hmac? The default could be settings.SECRET_KEY for backwards compatibility. I have so far not contributed to django, but I would like to start and I believe, this small change might be a good start. If you agree, I could open a ticket in trac. Best Regards, Jann -- 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/ca9e1cde-002d-491b-899a-02bfd50fbed6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Add ability to choose a different secret for PasswordResetToken
Thank you for your input. Yes I meant the PasswordResetTokenGenerator, sorry for this. It agree, it would be a fairly small addition to Django, however there doesn't seem to be an easy (non-hackish) way to get around. Since the impact on Django would be very small, I wanted to share my thoughts here. In our scenario, the self-service site is basically a small subset of our internal site. So if somebody would gain access to our interal site, he/she would already have access to a superset of data of the other site. So there is really no point to also take over to the other site. I'll give the override_settings a closer look, but this seems like something one wouldn't want in a production environment. Am Samstag, 18. März 2017 10:32:06 UTC+1 schrieb Adam Johnson: > > Presumably you mean PasswordResetTokenGenerator when you write > PasswordResetToken. > > Seems like a fairly small feature, but my security sense is tingling when > you say you're putting the secret key of one application in a variable for > another. > > Normally in a situation where multiple applications need to share login > data, I would consider having a centralized application for identity > management. > > Also in your current structure, you don't necessarily need to replace > _make_token_with_timestamp (which is prone to break if Django changes > that code) - you could (somewhat hackily) wrap > with override_settings(SECRET_KEY=other_key) around your call to > PasswordResetTokenGenerator.make_token. > > On 17 March 2017 at 20:54, jann.haber via Django developers (Contributions > to Django itself) > wrote: > >> Hi everybody, >> >> I have two sites in my project. One is for internal use to add members of >> our club to our database, one is a self-service page for our members. >> On registration of a member using our internal site, I want to send a >> password reset link to the member for easy registration to our self-service >> page. >> Since the two sites run on different servers and different SECRET_KEYs, I >> need to specify a different secret for the token generated with our >> internal site to work on the self-service page. >> I managed to do so by overwriting the method _make_token_with_timestamp >> of PasswordResetToken, however, I think this is quite an ugly solution. >> >> How would you think about the secret being an attribute of the >> PasswordResetToken class, which is then passed to salted_hmac? The default >> could be settings.SECRET_KEY for backwards compatibility. >> >> I have so far not contributed to django, but I would like to start and I >> believe, this small change might be a good start. If you agree, I could >> open a ticket in trac. >> >> Best Regards, >> Jann >> >> -- >> 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-develop...@googlegroups.com . >> To post to this group, send email to django-d...@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/ca9e1cde-002d-491b-899a-02bfd50fbed6%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/ca9e1cde-002d-491b-899a-02bfd50fbed6%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Adam > -- 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/4e1c275f-1ea5-482d-affa-e70b95ffac24%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: For discussion: JSON-aware views for error responses
+1 from me - At least for 400, 500, and CSRF errors, send JSON (or empty response) > back instead of HTML if the request is xhr or has JSON headers > It's possible to detect requests for JSON with request.accepts() , which the previous PR from vanadium23 predates. There's no way to detect "if the request is xhr" - we removed request.is_ajax because it only detected requests made with jQuery and some other libraries. > - Make it easy to override the JSON like we can do with HTML > I think we don't need to add new extension points. If you want custom JSON or HTML, you can provide your own views. These views can always "return custom JSON *or* call Django's built-in views". On Sat, Apr 23, 2022 at 6:16 AM vanadium23 wrote: > I've done some work long ago. May be will help for someone. > https://github.com/django/django/pull/8947 > > On Friday, 22 April 2022 at 08:53:56 UTC+3 Tobias Bengfort wrote: > >> +1 from me. >> >> On 14/04/2022 11.03, Ville Säävuori wrote: >> > And to be clear, I understand we already have middleware APIs and >> > various settings to handle this but my point is that I think handling >> > this in Django core (even as an optional setting or middleware) would >> be >> > most useful and right way to do this for the community. >> >> Can you provide some examples? I support the general idea, but having >> some concrete APIs to discuss might be helpful. >> >> thanks >> tobias >> > -- > 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/744c3b96-4c42-4eac-a451-5c6f6da446fdn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/744c3b96-4c42-4eac-a451-5c6f6da446fdn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM0inQhY3q6oVZEV-ELmSYHKtHrHm53wJ2OQ68mq1JTpew%40mail.gmail.com.
Re: How to stop the increment of Primary Key field when an trasaction fails.
Hi! I'm going to answer your question, but please read the below as well about where to ask questions in future. You can't stop ID's being consumed during a transaction - databases do this by default to avoid any potential confusion between "versions" of objects with the same ID. But if you absolutely need contiguous ID sequences, you can use the package django-sequences ( https://github.com/aaugustin/django-sequences ) to achieve this. It reduces concurrency though as it requires extra locking to do so. ... I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely to answer your support query with their limited time and energy. For support, please follow the "Getting Help" page: https://docs.djangoproject.com/en/stable/faq/help/ . This will help you find people who are willing to support you, and to ask your question in a way that makes it easy for them to answer. Thanks for your understanding and all the best, Adam On Sun, Apr 24, 2022 at 3:27 PM Satyabrata Sbr wrote: > How can i stop auto increment of primary key field of a model when some > exception occurs inside transaction.atomic()? > > -- > 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/6b555ca1-9ede-4193-8a50-206f9071cd3bn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/6b555ca1-9ede-4193-8a50-206f9071cd3bn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM2JYjCi8JPFRTfYpz_Xs8B1gnRnbNGCufNoZS5Bmz18ig%40mail.gmail.com.
Re: Correct this django error????
Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely to answer your support query with their limited time and energy. For support, please follow the "Getting Help" page: https://docs.djangoproject.com/en/stable/faq/help/ . This will help you find people who are willing to support you, and to ask your question in a way that makes it easy for them to answer. Thanks for your understanding and all the best, Adam On Sat, Apr 30, 2022 at 9:11 AM Arshad Noman wrote: > Page not found (404) > > Request Method:GETRequest > > URL:http://127.0.0.1:8000/delete_issue// > > Using the URLconf defined in LibraryManagementSystem.urls, Django tried > these URL patterns, in this order: > > admin/ > [name='index'] a > dd_book/ [name='add_book'] > view_books/ [name='view_books'] > view_books_student/ [name='view_books_student'] > view_students/ [name='view_students'] > issue_book/ [name='issue_book'] > view_issued_book/ [name='view_issued_book'] > student_issued_books/ [name='student_issued_books'] > profile/ [name='profile'] > edit_profile/ [name='edit_profile'] > student_registration/ [name='student_registration'] > change_password/ [name='change_password'] > student_login/ [name='student_login'] > admin_login/ [name='admin_login'] > logout/ [name='logout'] > delete_book// [name='delete_book'] > delete_student// [name='delete_student'] > delete_issue// [name='delete_issue'] > ^media/(?P.*)$ > > The current path, delete_issue//, didn’t match any of these. > > -- > 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/c7c2aa87-2d1d-4ad9-b28e-1ba476110b07n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/c7c2aa87-2d1d-4ad9-b28e-1ba476110b07n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM3Q1RsCBABHM-S_OHGcVVUJ7JpEbTNS_414RwoDRb0NXA%40mail.gmail.com.
Re: Web based movie app
Hi! You have indeed found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely to answer your support query with their limited time and energy. For support, please follow the "Getting Help" page: https://docs.djangoproject.com/en/stable/faq/help/ . This will help you find people who are willing to support you, and to ask your question in a way that makes it easy for them to answer. Thanks for your understanding and all the best, Adam On Thu, May 5, 2022 at 8:32 AM Arshad Noman wrote: > Is this the wrong mailing list for this post given below or fine? > > > > I want to make a web-based movie app in Django with data already given in > a JSON file. The first page will be movie listings and the second page for > details separate from other movie details means each movie details on a > separate page. A JSP search bar is also required on top to search movies. > > -- > 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/1c9dd6e7-261c-4c71-9b37-6c27870d2f7en%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/1c9dd6e7-261c-4c71-9b37-6c27870d2f7en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM2oMbkyKKMgQJwTuvOr-n%3Dwu06F-SkKC%2BqCJwM5-tZunA%40mail.gmail.com.
Re: Custom template directory name in apps
I agree with Mariusz.
Moreover, the app directories loader class is really small. You can create
a project-specific version in 3 lines, if you need:
class Loader(FilesystemLoader):
def get_dirs(self):
return get_app_template_dirs("email-templates")
On Tue, May 10, 2022 at 6:27 AM Mariusz Felisiak
wrote:
> Hi,
>
> Thanks for the proposition. I'm not sure why the new option is better
> than using subdirectories in *"templates" *e.g. *"templates/mail/".*
>
> Best,
> Mariusz
>
> --
> 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/fb7408c2-aa2d-4dfb-a624-a042a68e5b55n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/fb7408c2-aa2d-4dfb-a624-a042a68e5b55n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMyDDM0D4n_1yDrjxZ%3Dx7ZVzcnyMz3u7nSp1avGcamQdkz81HQ%40mail.gmail.com.
Re: Performance does not scale when increasing file upload sizes
Ferran - No, this is the right place. Noxx is suggesting a change to Django. Noxx - it seems reasonable to improve Django here. You mentioned ASGI - did you check what the WSGI paths do? It may be that the newer ASGI code is simply less optimal. Would it be possible to reduce the workflow to a single write call? > This is indeed the question. Could you investigate further and perhaps come up with a patch? You're likely "the world expert" on this part of Django at this point, after all the profiling you've done. On Wed, May 11, 2022 at 5:44 PM Ferran Jovell wrote: > This is still the wrong place. Try django-users mailing list. > > El dc., 11 de maig 2022, 17:53, 'Noxx' via Django developers > (Contributions to Django itself) va > escriure: > >> Story >> >> Our application supports many file uploads. >> In normal circumstances, those files are only a few megabytes to of >> around 100MB. >> However, some uploads can be several GB in size (10-15GB and up). >> >> I know, that file uploads with such a size can be handled differently, >> e.g. using a seperate endpoint, allowing slow requests to be served >> seperately from the application etc. >> and only to reference those files in a final request. >> This solution would introduce some other problems regarding >> house-keeping, non-atomic requests etc, thus I want to ignore this >> workaround for now. >> Performance impact: >> <https://code.djangoproject.com/ticket/33699#Performanceimpact:> >> >> The impact can be best observed when uploading a file which is bigger in >> it's size, e.g. 1GB+. >> On my maschine it takes the client around 700ms to send the request to >> the application, but than waits around 1.5s for the final response. >> Of course, those numbers are dramatically influenced additionally in >> production by storage speed, file size, webserver (uvicorn/daphne/..), >> load-balancers etc. >> But the final take here is, that the server does some additional work >> after the client finished its request. >> In a production-like environment the numbers peaks to 4s (send request) >> and 16s (waiting for response) for the same file size. Uploading a 3GB >> file, the numbers are 11s and 44s. >> As you can see, the 44s are very near the default gateway timeout of >> Nginx and the hard-coded one of AWS load-balancers. >> As soon as the server needs more than 60s to create the response, the >> client will get a gateway timeout error. >> Workflow of file uploads: >> <https://code.djangoproject.com/ticket/33699#Workflowoffileuploads:> >> >> I'm not a Django-dev, so please correct me if I'm wrong. As far as I >> understand, the uploaded file is processed as the following: >> >> Given, that the application is running within an ASGI server, the whole >> request is received by the ASGIHandler. >> It's method #read_body creates a SpooledTemporaryFile. >> This temporary file contains the whole request body, including POST >> parameters and files. >> >> As soon as the request has been received (this is the point the client >> finished uploading the file) it is than transformed into an ASGIRequest. >> The ASGIRequest has #_load_post_and_files and #parse_file_upload as >> methods which parses the body into seperate files. >> This is done by reading the body (the temporary file) and iterating over >> them seperated by the POST seperator done by MultiPartParser. >> The generated chunks are than sent to upload handlers which process those >> files further on using #receive_data_chunk. >> The default upload handlers provided by Django will write those files to >> disc again, depending on their size. >> Problem <https://code.djangoproject.com/ticket/33699#Problem> >> >> The problem here is, that the uploaded file(s) are transformed and >> written as well as read multiple times. >> First the whole body is written into a SpooledTemporaryFile which is >> re-read using streams (LazyStream) just to be written once more by an >> upload handler. >> >> The impact is low if the uploaded file is small, but increases >> dramatically if the size is increased, the file hits the disc and/or the >> storage is slow. >> Optimization / Brainstorming >> <https://code.djangoproject.com/ticket/33699#OptimizationBrainstorming> >> >> Would it be possible to reduce the workflow to a single write call? >> E.g. if the ASGIHandler already splits the request body into seperate >> files, it would be possible to just forward the file pointers until the >> upload handlers ne
Re: Equality check for two QuerySet
I don't think there can be a performant way to compare two querysets.
Moreover, which features should be considered in equality would be very
complicated, when you consider the more involved parts of the API like
database functions, annotations, subqueries, etc.
One can check via the database if two queries give the same results with
the difference() method:
https://docs.djangoproject.com/en/4.0/ref/models/querysets/#django.db.models.query.QuerySet.difference
. For example:
querysets_the_same = not qs1.difference(qs2).exists()
On Wed, May 11, 2022 at 2:41 PM mohamad ali mehdizadeh
wrote:
> Python `==` operator does not check references, it checks values, so qs2
> is a copy of qs1 but its value is the same so == must be True as it's not
> now.
> So I have a simple solution.
> def __eq__(self, other):
> if not isinstance(other, self.__class__):
> raise ValueError('Cannot compare a QuerySet to a non-QuerySet.')
> if not self.query.can_filter():
> return NotImplemented
> return not self.difference(other).union(other.difference(self)).exists()
>
> On Wednesday, May 11, 2022 at 12:14:51 AM UTC+4:30 ma...@wpsoft.at wrote:
>
>> I am not Agree.
>>
>> qs1.all() it is copy from qs1, the new object.
>>
>>
>>
>> I already try to write QuerySet compare on the Django 1.4 and i remember,
>>
>> that str(qs1.query) can be different as str(qs2.query), I am not Shure.
>>
>>
>>
>> Mit freundlichen Grüßen,
>>
>> DI Mag. Maxim Danilov
>>
>>
>>
>> +43(681)207 447 76
>>
>> ma...@wpsoft.at
>>
>>
>>
>> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com]
>> *On Behalf Of *mohamad ali mehdizadeh
>> *Sent:* Tuesday, May 10, 2022 5:09 PM
>> *To:* Django developers (Contributions to Django itself) <
>> django-d...@googlegroups.com>
>> *Subject:* Equality check for two QuerySet
>>
>>
>>
>> Hi.
>> Why we don't have __eq__ for QuerySets, here is an example:
>> ```
>>
>> qs1 = Model.objects.all()
>>
>> qs2 = qs1.all()
>>
>> qs1 == qs2
>>
>> ```
>>
>> output: False
>>
>> as we know these two are the same by value!
>>
>> --
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/80e878f8-8701-40ad-92a0-5c689df27ec2n%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/80e878f8-8701-40ad-92a0-5c689df27ec2n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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/a930c0e1-6cc9-4894-8922-a07aedad3fcdn%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/a930c0e1-6cc9-4894-8922-a07aedad3fcdn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMyDDM2tir72pSEDoRUFLB%2Bof1tCcokEUZ%2BRED6U8GJQduqXVg%40mail.gmail.com.
Re: Blocking disposable or temporary email addresses
Hi Yonas, Thanks for sharing this list. Even so, in my opinion, this feature lives best outside of Django where it can be appropriately customized as needed for a given project. I hope this helps. Best, Tobias On Wed, May 11, 2022, 6:46 PM Yonas wrote: > > Would syncing the block list from repos like > https://github.com/disposable-email-domains/disposable-email-domains > (actively maintained since 2014) ease the burden of updating the list? > On Thursday, May 12, 2022 at 12:44:28 AM UTC+3 James Bennett wrote: > >> On Wed, May 11, 2022 at 2:21 PM Yonas >> wrote: >> >>> What does the community think about adding a feature to Django where >>> disposable or temporary emails are not accepted during account registration? >> >> >> I used to try to do this in my django-registration package, but >> eventually gave up on it because maintaining an up-to-date list of all >> possible domains and other patterns was not feasible. I expect the same >> would be true with Django — it would require frequent updates to the list >> of domains/patterns to block, and people would complain that the updates >> weren’t fast enough, because Django only releases once a month (and that’s >> assuming updates to the blocked email list would be considered for >> inclusion in the monthly bugfix releases, rather than only at feature >> release updates). >> >> So I expect this isn’t something Django could or should do. >> > -- > 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/b669801b-f695-49c2-9d04-2ff7db74dc58n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/b669801b-f695-49c2-9d04-2ff7db74dc58n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMGFDKRONKrsAw35VBN8%3DYiNWkEzQWd5kUcYH1G8CjqG2eo%3DbQ%40mail.gmail.com.
Re: Blocking disposable or temporary email addresses
I would say this feature is a bit more questionable these days, since even big companies like Apple provide "disposable" email addresses for privacy protection. And I also agree this would be better in a separate package, where updating the list of domains would be easier and not tied to Django's eight-monthly release cycle. On Thu, May 12, 2022 at 1:09 AM 'Tobias McNulty' via Django developers (Contributions to Django itself) wrote: > Hi Yonas, > > Thanks for sharing this list. Even so, in my opinion, this feature lives > best outside of Django where it can be appropriately customized as needed > for a given project. > > I hope this helps. > > Best, > Tobias > > > On Wed, May 11, 2022, 6:46 PM Yonas > wrote: > >> >> Would syncing the block list from repos like >> https://github.com/disposable-email-domains/disposable-email-domains >> (actively maintained since 2014) ease the burden of updating the list? >> On Thursday, May 12, 2022 at 12:44:28 AM UTC+3 James Bennett wrote: >> >>> On Wed, May 11, 2022 at 2:21 PM Yonas >>> wrote: >>> >>>> What does the community think about adding a feature to Django where >>>> disposable or temporary emails are not accepted during account >>>> registration? >>> >>> >>> I used to try to do this in my django-registration package, but >>> eventually gave up on it because maintaining an up-to-date list of all >>> possible domains and other patterns was not feasible. I expect the same >>> would be true with Django — it would require frequent updates to the list >>> of domains/patterns to block, and people would complain that the updates >>> weren’t fast enough, because Django only releases once a month (and that’s >>> assuming updates to the blocked email list would be considered for >>> inclusion in the monthly bugfix releases, rather than only at feature >>> release updates). >>> >>> So I expect this isn’t something Django could or should do. >>> >> -- >> 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/b669801b-f695-49c2-9d04-2ff7db74dc58n%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/b669801b-f695-49c2-9d04-2ff7db74dc58n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAMGFDKRONKrsAw35VBN8%3DYiNWkEzQWd5kUcYH1G8CjqG2eo%3DbQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAMGFDKRONKrsAw35VBN8%3DYiNWkEzQWd5kUcYH1G8CjqG2eo%3DbQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM3w6RGHhtj3%3DU7irivW4dbfUmbmZjOT0VdYKSWM9s-Bpw%40mail.gmail.com.
Update security docs re HOST header and ALLOWED_HOSTS?
There's a vague warning in the security docs <https://docs.djangoproject.com/en/4.0/topics/security/#host-header-validation> that says: > many common web servers [have] a configuration that seems to validate the > Host header [that] may not in fact do so. For instance, even if Apache is > configured such that your Django site is served from a non-default virtual host > with the ServerName set, it is still possible for an HTTP request to match this > virtual host and supply a fake Host header. Does anybody know if this applies to *any* other server? The way it causes problems in Apache is very specific, and should be really really uncommon since the web has moved to HTTPS by default. (If the HOST header on the request doesn't match a named virtual host in Apache, and it doesn't match a host via SSL's Server Name Indication (SNI), Apache forwards the request to the first named virtual host <https://httpd.apache.org/docs/trunk/vhosts/details.html>). If there's no other server we know of that this impacts, I'd suggest we tighten this warning to explain that it only applies to Apache without SSL, or maybe we even remove this warning altogether? I spent some time today researching this because I wanted to make sure the issue didn't apply to the server I'm using (AWS ELB — It doesn't). It's always good to clean up old warnings if we can. Thanks, Mike -- 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/7e8c8674-55a6-4b63-b8d4-7626b56b72e6n%40googlegroups.com.
Re: Experience with black formatting in django
Hi! Although the DEP for Black was written several years ago, we only actually adopted it in the code base in February this year. The DEP determined to use Black when it was no longer beta, and that took a while :) I think the reformatting was fairly popular, many people have given positive reactions on the PR: https://github.com/django/django/pull/15387 . My impression is there's only a minority who dislike Black, and often only one thing like the choice of double quotes. The fellows (Carlton and Mariusz) do most of the day-to-day work, and they would have a better view on whether there has been any friction with new or returning contributors. I know that rebasing the existing branches was a bit of work, but one off. Personally I adopted Black across the open source projects I maintain years ago, and haven't had any problems. I use pre-commit and pre-commit.ci to run Black and automatically reformat PR's. This means even contributors don't need to run it locally. My advice would be to adopt :) All the best, Adam On Tue, May 17, 2022 at 3:04 PM Tom Aldcroft wrote: > The astropy project is currently considering implementing code formatting > with black, much as Django did in 2019. I was happy to see the case for > transitioning to black formatting in Django DEP-0008 ( > https://github.com/django/deps/blob/main/final/0008-black.rst). I think > it captures the key points both pro and con, along with the inevitable lack > of complete consensus in a large project. > > My goal in writing is to request feedback from Django developers about how > this transition has impacted django development and community engagement in > the three years since the transition. > > Has there been specific feedback from contributors (both experienced and > new) related to black autoformatting? > >- Ease of actually running black and meeting the black-format standard >for PRs. Have there been technical problems that required assistance? >- Style considerations? > > Have most core developers accepted or embraced the black style at this > point? The DEP included some testimonials to that effect, but some of us > wondered if those represented a fair sampling of the community. > > Are there any regrets or things you would change? > > Do you have any advice for the astropy project? > > Any feedback from your experience would be most appreciated. > > Regards, > Tom (@taldcroft on GitHub) > > -- > 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/33b9a27e-2a0c-4e7c-ba2b-c5072a87073an%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/33b9a27e-2a0c-4e7c-ba2b-c5072a87073an%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM1j0pa%3D5iQeFL%2BZr4QOb2-kjYtj%2BRG%3DPNsxsEv0RqDTRg%40mail.gmail.com.
Re: Features deprecated in 4.1 / Log out via GET
Hi Uri, The view raises a RemovedInDjango50Warning, which on Django 4.1 inherits from PendingDeprecationWarning: https://github.com/django/django/blob/ac6410ec071f53893914c82e820a2320866681df/django/utils/deprecation.py#L12 You'll need to run with "python -W all" or similar to see it (consider development mode <https://docs.python.org/3.10/library/devmode.html>). Python's default warning filters will only show DeprecationWarning, which is "the next level up", and what Django 4.2 will use for RemovedInDjango50Warning. On Thu, May 19, 2022 at 8:28 PM אורי wrote: > Hi, > > I installed Django 4.1 alpha and ran the tests with deprecation warnings > enabled, but I didn't get any deprecation warnings for logging out with > get. I have this test: > > def test_user_can_logout(self): > r = self.client.get(path='/logout/') > self.assertEqual(first=r.status_code, second=200) > r = self.client.get(path='/') > self.assertIs(expr1=r.context['user'].is_authenticated, > expr2=False) > > And I ran it with the command > `./tests_manage_all_sites_with_deprecation_warnings.sh test > speedy.core.accounts.tests.test_views.LogoutViewTestCase`, and the test is > passing without any deprecation warnings. Is it a problem with Django 4.1 > or in the way I ran the test? > > Do you want me to file a new ticket? > > Thanks, > Uri. > אורי > u...@speedy.net > > -- > 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/CABD5YeFEdxPt3Yxbv3Ws3EFxmnswmXb9qhsLk1NH-%2BaLucwyxQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CABD5YeFEdxPt3Yxbv3Ws3EFxmnswmXb9qhsLk1NH-%2BaLucwyxQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM3m9pHb23%2BJN9Efc%2BvN%3DMDz8Penk0FOM_xBLECOR833bw%40mail.gmail.com.
Re: Features deprecated in 4.1 / Log out via GET
Great. There's some more information on warnings in the docs here: https://docs.djangoproject.com/en/4.0/howto/upgrade-version/#resolving-deprecation-warnings . On Thu, May 19, 2022 at 9:38 PM אורי wrote: > Hi Adam, > > I understand, and with `python -W all` I can see this warning (it was with > `python -W error::DeprecationWarning` that I didn't see the warning). > > Thanks, > Uri. > אורי > u...@speedy.net > > > On Thu, May 19, 2022 at 10:52 PM 'Adam Johnson' via Django developers > (Contributions to Django itself) > wrote: > >> Hi Uri, >> >> The view raises a RemovedInDjango50Warning, which on Django 4.1 inherits >> from PendingDeprecationWarning: >> https://github.com/django/django/blob/ac6410ec071f53893914c82e820a2320866681df/django/utils/deprecation.py#L12 >> >> You'll need to run with "python -W all" or similar to see it (consider >> development >> mode <https://docs.python.org/3.10/library/devmode.html>). Python's >> default warning filters will only show DeprecationWarning, which is "the >> next level up", and what Django 4.2 will use for RemovedInDjango50Warning. >> >> On Thu, May 19, 2022 at 8:28 PM אורי wrote: >> >>> Hi, >>> >>> I installed Django 4.1 alpha and ran the tests with deprecation warnings >>> enabled, but I didn't get any deprecation warnings for logging out with >>> get. I have this test: >>> >>> def test_user_can_logout(self): >>> r = self.client.get(path='/logout/') >>> self.assertEqual(first=r.status_code, second=200) >>> r = self.client.get(path='/') >>> self.assertIs(expr1=r.context['user'].is_authenticated, >>> expr2=False) >>> >>> And I ran it with the command >>> `./tests_manage_all_sites_with_deprecation_warnings.sh test >>> speedy.core.accounts.tests.test_views.LogoutViewTestCase`, and the test is >>> passing without any deprecation warnings. Is it a problem with Django 4.1 >>> or in the way I ran the test? >>> >>> Do you want me to file a new ticket? >>> >>> Thanks, >>> Uri. >>> אורי >>> u...@speedy.net >>> >>> -- >>> 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/CABD5YeFEdxPt3Yxbv3Ws3EFxmnswmXb9qhsLk1NH-%2BaLucwyxQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/django-developers/CABD5YeFEdxPt3Yxbv3Ws3EFxmnswmXb9qhsLk1NH-%2BaLucwyxQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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/CAMyDDM3m9pHb23%2BJN9Efc%2BvN%3DMDz8Penk0FOM_xBLECOR833bw%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAMyDDM3m9pHb23%2BJN9Efc%2BvN%3DMDz8Penk0FOM_xBLECOR833bw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CABD5YeG4Z7nKs%2BxGRWGdFbxNGAi9tsm2W53fxt%2B4MuKyiOfdgw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CABD5YeG4Z7nKs%2BxGRWGdFbxNGAi9tsm2W53fxt%2B4MuKyiOfdgw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM3yR1793qkBWTbNpVh%3D1L6OKwq0gPKOFuwHsQYqxKRj2A%40mail.gmail.com.
Re: Add request object as optional input to BaseForm class
I don't think this is a good idea, it couples forms too tightly to requests. The idea of a form is to take dictionaries of form inputs, and validate those. It shouldn't need the request. If I write a form class that needs extra things from the request, I write my form class to take just that thing. For example, the current user from request.user. On Tue, May 24, 2022 at 2:05 AM Douglas Mumme wrote: > Hey all, > > I've recently made a ticket to add the request object as an optional input > to the BaseForm class so that it will easily input for any form if it's > needed. > > I found out that something like this has been requested before and > resolved as a "won't fix", but I think adding it as an optional input will > be an easy way developers can pass it through when needed without having to > subclass the Form class. > > I think a lot of people need the request object in forms for validation > and for queryset filtering and this will make life just a little easier. > > I would love to hear everyone's thoughts and if this is a good idea. > > Thanks! > > Ticket url: https://code.djangoproject.com/ticket/33732 > > -- > 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/cd528f14-322b-4786-986c-82f06172ea4en%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/cd528f14-322b-4786-986c-82f06172ea4en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM0_eEhoV6Bod2TdSiqj5kNWAZXohNjS%3DF062G1U0_hvtw%40mail.gmail.com.
Re: Postgresql Sequence update on data migration
Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely to answer your support query with their limited time and energy. For support, please follow the "Getting Help" page: https://docs.djangoproject.com/en/stable/faq/help/ . This will help you find people who are willing to support you, and to ask your question in a way that makes it easy for them to answer. Thanks for your understanding and all the best, Adam On Wed, May 25, 2022 at 7:10 PM mohammad ali mehdizadeh < am.civi...@gmail.com> wrote: > Matthew thank you for your attention > I mean we have a scenario that can make errors. > We have a sequence for a primary key, if we insert some objects with > predefined `id` and then we let the sequence create a key for us, then we > will have a duplicate primary key error. > Do you mind django want to prevent it? > Or it's developer responsibility? > > On Wed, May 25, 2022 at 7:03 PM Matthew Pava wrote: > >> Please see: >> >> https://docs.djangoproject.com/en/dev/ref/django-admin/#sqlsequencereset >> >> >> >> Also, this question is more for the Django Users mailing list than the >> Django Developers mailing list. >> >> >> >> *From:* django-developers@googlegroups.com < >> django-developers@googlegroups.com> *On Behalf Of *mohamad ali mehdizadeh >> *Sent:* Wednesday, May 25, 2022 1:23 AM >> *To:* Django developers (Contributions to Django itself) < >> django-developers@googlegroups.com> >> *Subject:* Postgresql Sequence update on data migration >> >> >> >> I have a migration from an old table to a new table, so when I migrate >> also data of old table, I try to keep PrimaryKey values the same as old >> table. so every thing go well until I see primary key duplicate value >> errors from Postgresql, I check it and so the Sequence of the new table was >> not get the last_value of the old table, >> I doubt that is it the responsibility of developer to take it to the >> account or Django can help developer here? >> >> -- >> 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/fd70a069-0704-40b7-9fe9-e59d87fef22an%40googlegroups.com >> <https://us-east-2.protection.sophos.com?d=google.com&u=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzL2ZkNzBhMDY5LTA3MDQtNDBiNy05ZmU5LWU1OWQ4N2ZlZjIyYW4lNDBnb29nbGVncm91cHMuY29tP3V0bV9tZWRpdW09ZW1haWwmdXRtX3NvdXJjZT1mb290ZXI=&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=TzFrcXFEMVFUaHg3VS9iWWtZcEFpNXpDOHlVMkdXemx6UWl5RW5GdDRtVT0=&h=90200e729fae4913bde29ed6523fab68> >> . >> >> -- >> 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/13a63536e5114b27938bd23d518350c3%40Exchange.ISS.LOCAL >> <https://groups.google.com/d/msgid/django-developers/13a63536e5114b27938bd23d518350c3%40Exchange.ISS.LOCAL?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAHFc_GdP_kufUVk7-uYEH%3DOs_pFUqzaaEEqJOBuXNXGBOz%2Bwnw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAHFc_GdP_kufUVk7-uYEH%3DOs_pFUqzaaEEqJOBuXNXGBOz%2Bwnw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM0yc4JmZmyOi%3D8Wn9eiq%2B6vfyc4Y9Y23uGC_RQHxAtAAw%40mail.gmail.com.
Re: get_random_secret_key not documented!?
Python's secrets module has token_hex and a short recipe for generating random strings: https://docs.python.org/3.10/library/secrets.html#recipes-and-best-practices . I don't think Django needs to provide a public function here. I would advise Digital Ocean to recommend the secrets module. On Wed, Jun 1, 2022 at 10:22 AM Fab wrote: > There isn't a recommended way so you can generate it however you want. The > function is used in the startproject > <https://github.com/django/django/blob/0dd29209091280ccf34e07c9468746c396b7778e/django/core/management/commands/startproject.py#L19> > command > for convenience. > > On Monday, 16 May 2022 at 13:09:36 UTC+1 Sam wrote: > >> In the DigitalOcean documentation >> <https://docs.digitalocean.com/tutorials/app-deploy-django-app/#setting-the-secret-key> >> I just found that they use >> `from django.core.management.utils import get_random_secret_key` >> to generate a new, unique secret key. >> >> I didn't know that there was such a function. >> and the get_random_secret_key function seems to be not documented so far >> <https://docs.djangoproject.com/en/4.0/ref/utils/>. >> >> Is this the recommended way to generate secret keys for Django apps? >> If that's the case wouldn't it make sense to write a piece of >> documentation for that? >> >> Kind regards, >> Samuel✌ >> > -- > 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/b2018ec8-0cc0-475e-8ede-81f10c1e193bn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/b2018ec8-0cc0-475e-8ede-81f10c1e193bn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM2TiTctT9uEL1gvy%3DGo8NfoYmYBUsuOx0LtS5TGgAKdAg%40mail.gmail.com.
Re: Feature Idea for overwrite_default_connection context manager
Modifying the connections object seems like the wrong way to approach this, as it's not intended for mutation. Did you consider writing a database router and then having a context manager that affects the router's state? https://docs.djangoproject.com/en/4.0/topics/db/multi-db/#topics-db-multi-db-routing . That is the API Django supports for moving queries to different databases. On Wed, Jun 1, 2022 at 2:21 PM Alexander Lyabah wrote: > In some of the previous version on Django I had a very useful context > manager. > > from contextlib import ContextDecorator > from django.db import connections > > class overwrite_default_connection(ContextDecorator): > prev_default = None > write_connection = None > > def __init__(self, write_connection): > self.write_connection = write_connection > > def __enter__(self): > self.prev_default = connections['default'] > connections['default'] = connections[self.write_connection] > return self > > def __exit__(self, *exc): > connections['default'] = self.prev_default > return False > > Which allows me to overwrite default connection. It is very useful when > you use a jupyter notebook and you need to switch between db connections > that have different data but the same structure (django models) > > But the shared implementation of that context manager stops working > recently > > ValueError: Subqueries aren't allowed across different databases. Force > the inner query to be evaluated using `list(inner_query)`. > > But I'm wondering wouldn't it be useful to have that kind of manager in > the core Django functionality, or it is a stupid idea? > > Thank you > > -- > 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/ad453105-2116-40c9-a1ff-9571bfb080d1n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/ad453105-2116-40c9-a1ff-9571bfb080d1n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM0WUdGP3RKZzmNDq7VYYxoXQqXaJW8wRGU57Tr8174CdQ%40mail.gmail.com.
Re: JsonResponse have a DEFAULT_JSON_ENCODER setting
I don't think that's necessary, you can create a subclass of JSONField with the encoder you want, or even faster use functools.partial() as I blogged about here: https://adamj.eu/tech/2021/05/05/3-uses-for-functools-partial-in-django/#making-reusable-fields-without-subclassing On Thu, Jun 23, 2022 at 9:11 PM Steve Jorgensen wrote: > I think that seems like a good thing to be able to configure. > > On Thursday, June 23, 2022 at 7:54:56 AM UTC-7 Fab wrote: > >> Hey, >> >> With JsonResponse instead of the encoder defaulting to DjangoJSONEncoder >> I was thinking it would be nice to have a setting like DEFAULT_JSON_ENCODER >> so I can set another one if needed without having to change all my usages >> already set. >> >> >> https://github.com/django/django/blob/0dd29209091280ccf34e07c9468746c396b7778e/django/http/response.py#L676 >> >> Is there any reason not to do this? Feels like it wont break backwards >> compatibility. >> >> Regards, >> >> Fab >> > -- > 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/0eff9638-f455-4a64-a507-b47c6bd2cff0n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/0eff9638-f455-4a64-a507-b47c6bd2cff0n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM2DzWneRNCHk0psdinCehJmvw71PSw1Fh5RBfYcsZktww%40mail.gmail.com.
Re: RE : Email on App
Indeed this is the wrong mailing list. For support not just on email, you can follow the "Getting Help" page: https://docs.djangoproject.com/en/stable/faq/help/ . This will help you find people who are willing to support you, and to ask your question in a way that makes it easy for them to answer. Thanks for your understanding and all the best, Adam On Tue, Jul 5, 2022 at 7:44 AM Ferran Jovell wrote: > Hi Arun, > > This is the wrong mailing list to ask this question. This is the mailing > list for the actual development of django. Instead, I think you are looking > for django-users mailing list. > > Cheers. > > El dl., 4 de jul. 2022, 22:47, Arun va escriure: > >> Hai , >> >> i am have requirement , user need to send email after login into app with >> login user email >> >> where , i tried to send with default but i need to use from email as >> login user email >> can any one clear my issue. >> >> Thanks >> Arun >> >> -- >> 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/44e4b31e-5933-46de-a713-9aa8d0e33fe3n%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/44e4b31e-5933-46de-a713-9aa8d0e33fe3n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAEKh-smND2w18JQY1Mw4hFadzwFfixz1aAWVSpHE_duJ3uNvKg%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAEKh-smND2w18JQY1Mw4hFadzwFfixz1aAWVSpHE_duJ3uNvKg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM1xhBBQohjsCRVUtFcFXZ%3DdyAfBA80xqkje%2B2xq2ZF%3DxQ%40mail.gmail.com.
Re: Hello everyone! Guide me in this journey.
Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely to answer your support query with their limited time and energy. For support, please follow the "Getting Help" page: https://docs.djangoproject.com/en/stable/faq/help/ . This will help you find people who are willing to support you, and to ask your question in a way that makes it easy for them to answer. Thanks for your understanding and all the best, Adam On Wed, Jul 6, 2022 at 9:42 PM ojas Gupta wrote: > My self Ojas Gupta currently doing by BTech from NIT Hamirpur. I want to > start my journey in open source and for that I need your valuable guidance. > Could you please show me the correct path so that I can start contributing. > > -- > 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/6005ba97-160e-498e-a4c7-87087e5c3e47n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/6005ba97-160e-498e-a4c7-87087e5c3e47n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM2g29MWaboK0YaDMgwXu4i9%3DZy%3DMA-XvYvhmwKK%3D403nw%40mail.gmail.com.
Re: Adding a script positional argument to dbshell
Hi dbshell already passes all unknown arguments through to the underlying program. For example on postgres you can use the psql '-c' option like so: $ ./manage.py dbshell -c 'select 123' ?column? -- 123 (1 row) argparse allows a -- separator to split arguments for dbshell and the underlying program, so you can even use "shadowed" options like --help like so: $ ./manage.py dbshell -- --help psql is the PostgreSQL interactive terminal. Usage: psql [OPTION]... [DBNAME [USERNAME]] General options: ... This should allow you to pass your scripts through to the oracle tool, if I understand your request correctly. Thanks, Adam On Tue, Jul 5, 2022 at 5:12 PM dans...@gmail.com wrote: > In Adam's blog post > https://adamj.eu/tech/2022/06/29/run-a-django-migration-by-hand/, he > shows a pattern I've used in the past. > > Would it be useful to support passing an optional positional argument to > dbshell that is then passed to the dbshell program appropriately? e.g., > with @filename for Oracle sqlplus or directly to mysql? I suppose that > might introduce new code to DatabaseOperations, but not too much. I think > only Oracle's DatabaseOperations would be different. > > I've had to extend Django to run some old PL/SQL via management commands. > This helped me with my 16 year old database to replace scripts that used > combinations of bash, ksh, sh, expect, perl, sqlplus, and PL/SQL with just > two three technologies - namely Python, Django, and PL/SQL. However, since > there are 20k lines of PL/SQL and 25k lines of Python, making the PL/SQL go > away is not yet a priority. > > I've done it basically by using code like this in a management command: > > https://gist.github.com/danizen/a3b5e3f8514be90b796f298dfb52f99e > > If you look at the "run_report" method of the basereport.py, you'll see > that I am using os.pipe() and os.dup2() to enable passing the output of a > template to dbshell. This is in case there is any sqlplus reliance in > these old reports. In my case, it will be better to assure that all of > this report code can run in management commands or directly via cursor > execute - and so I haven't proposed this for my use case. > > The one that Adam proposes makes a much better use case for this > additional positional argument to dbshell. > > Has this been discussed before? > > -- > 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/aeb4ef0d-e8d6-46c6-9aaa-167abd5de3e5n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/aeb4ef0d-e8d6-46c6-9aaa-167abd5de3e5n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM0w%2B4geWmO5xwVVPnvgkayZ4hjDRfzQZnW9UmQnzpiYZA%40mail.gmail.com.
Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()
I'm also against adding get_or_none(), for the same reasons. Adding a method to shortcut something that can already be done doesn't seem worth it to me. On Sat, Jul 9, 2022 at 1:56 PM Mariusz Felisiak wrote: > I'm against it because it's already easily achievable and it's debatable > how it should behave with many results. IMO any new method would be > confusing and in the case of unique filtering `get_or_none(unique_filters)` > would be an alias for `.filter(unique_filters).first()`. To me, this is > duplication of an API. > > There are several -0 in the previous thread (Shai, Florian) and you can > count -1 from me. > > Best, > Mariusz > > -- > 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/aeb9be96-ec03-48f9-ae97-2859b62a1df6n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/aeb9be96-ec03-48f9-ae97-2859b62a1df6n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM20TNRrFpDamKu%2Bc_Dxxbh0KH5pJjxxmqYLjL6CNzAW7g%40mail.gmail.com.
Re: database column order
I agree with Simon here. I don’t think Django should account for postgres column order, especially when there’s no way to change column positions other than by rebuilding the table. By the time you have enough data for the space savings to be valuable, you probably need to use a careful strategy to rebuild the table, perhaps using a view as the Postgres wiki page says. On Tue, 12 Jul 2022 at 23:11, charettes wrote: > Foreign keys are added at the end in cases where there are reference > cycles between models that must be broken. Instead of creating the column > first and then creating the foreign key constraint the migration framework > opted to combine both operations as it simplifies a few things. > > If you add fields to one your existing models the migration framework will > add them at the end of your table as that's the most straightforward way of > doing so. Of the top of my head only MySQL supports a syntax to add a > column to an existing table at a specific position and doing so basically > rebuilt the table (prior to 8.0.29[0]) which is what the Postgres wiki > suggests doing if you really want a particular physical layout[1]. > > As pointed out in the comments on HN there is some ongoing work to lift > this limitation on Postgres[2] but even if this lands in the next version > of Postgres we still have to figure out what should be done with historical > models that have a different field layout than their table. The migration > framework also doesn't have any notion of field ordering right now so that > would also be work that needs to be done. > > I'm of opinion that if you are experiencing performance issues due to the > physical layout of a particular table managed by Django you're likely > better off not relying on the automatically generated migrations that > Django provides and use a mix of `RunSQL` and `SeparateDatabaseAndState` to > achieve what you're after. > > Cheers, > Simon > > [0] > https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#online-ddl-column-syntax-notes > [1] https://wiki.postgresql.org/wiki/Alter_column_position > [2] > https://www.postgresql.org/message-id/flat/20220628083230.c4qhp4fdp3dp22ig%40jrouhaud > > Le mardi 12 juillet 2022 à 15:21:58 UTC-4, f.holop a écrit : > >> hello there, >> >> an interesting topic popped up on HN: >> >> Column order in PostgreSQL does matter >> https://news.ycombinator.com/item?id=32067473 >> >> I was wondering how django does this, so I looked at some of the sql >> generated by migrations in my apps (particularly initial ones) and if I >> read the SQL correctly django mostly matches column order with the model >> fields order with the notable exception of foreign key(s). Those being >> (by default and quite often) fixed width, and it seems that they might >> benefit from the order described in the articles, I was wondering what >> was the reason for putting them at the end. >> >> >> -f >> -- >> > -- > 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/b4fd0636-f5d7-44bb-a3cb-130e21e18b57n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/b4fd0636-f5d7-44bb-a3cb-130e21e18b57n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM00aNPuAMVP6NVaGHT-oT7zqqN0GU5A48-uEMQcJ_Jk1A%40mail.gmail.com.
Re: Feature Request: New parameter for render_to_string() to render part of a template using a selector
I’m also -1.
There are many ways to “partially render” a template. I covered one in the
Django-htmx docs mention one:
https://django-htmx.readthedocs.io/en/latest/tips.html#partial-rendering .
The proposal to render the full template and then throw away most of the
result is a particularly wasteful one :)
I think it would be a better avenue to explore other ways of organising
templates for different htmx patterns. I’d gladly consider documentation
PR’s for django-htmx.
On Sat, 16 Jul 2022 at 22:13, Ken Whitesell
wrote:
> I'm going to chime in as a -1 here.
>
> It does not seem to me that you can guarantee that you have the correct
> element(s) unless you actually render the complete template.
>
> Once you've rendered that template, then you can use tools like
> BeautifulSoup to extract the elements desired and ignore the rest.
>
> I don't see value in trying to replicate what BeautifulSoup provides
> within Django.
>
> Ken
>
> On 7/15/2022 8:21 PM, Dan Swain wrote:
>
> With the growing uptake of technologies like HTMX, I would like to see an
> additional parameter added to render_to_string(). In my rewritten
> definition of render_to_string() below (taken from the docs), I have named
> the parameter “part”. In rendering portions of a template for responses to
> ajax calls, these template portions end up being stored in separate
> template snippet files and then {% include(d) %} in the main template. I
> think that keeping everything related to a view in a single template file
> is much more desirable. Therefore, just include *part=selector* in order
> to pull out the part of the template that is needed for rendering. The
> file structure for managing templates would become much simpler with this
> approach.
>
>
>
> *render_to_string**(**template_name**, part=None, **context=None**, *
> *request=None**, **using=None**)¶
> <https://docs.djangoproject.com/en/4.0/topics/templates/#django.template.loader.render_to_string>*
>
> *render_to_string()* loads a template like *get_template()*
> <https://docs.djangoproject.com/en/4.0/topics/templates/#django.template.loader.get_template>
> and
> calls its *render()* method immediately. It takes the following arguments.
>
> *template_name*
>
> The name of the template to load and render. If it’s a list of template
> names, Django uses *select_template()*
> <https://docs.djangoproject.com/en/4.0/topics/templates/#django.template.loader.select_template>
> instead
> of *get_template()*
> <https://docs.djangoproject.com/en/4.0/topics/templates/#django.template.loader.get_template>
> to
> find the template.
>
> *part*
>
> An optional CSS selector that will be used to cause only the portion of
> the template that matches the selector to be rendered.
>
> *context*
>
> A *dict* <https://docs.python.org/3/library/stdtypes.html#dict> to be
> used as the template’s context for rendering.
>
> *request*
>
> An optional *HttpRequest*
> <https://docs.djangoproject.com/en/4.0/ref/request-response/#django.http.HttpRequest>
> that
> will be available during the template’s rendering process.
>
> *using*
>
> An optional template engine *NAME*
> <https://docs.djangoproject.com/en/4.0/ref/settings/#std-setting-TEMPLATES-NAME>.
> The search for the template will be restricted to that engine.
>
>
> --
> 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/1c8201d898aa%240449fe50%240cddfaf0%24%40shenberger.org
> <https://groups.google.com/d/msgid/django-developers/1c8201d898aa%240449fe50%240cddfaf0%24%40shenberger.org?utm_medium=email&utm_source=footer>
> .
>
>
> --
> 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/b39a36cc-89b5-968c-e0da-e4eeab04e3e5%40comcast.net
> <https://groups.google.com/d/msgid/django-developers/b39a36cc-89b5-968c-e0da-e4eeab04e3e5%40comcast.net?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMyDDM0bSg-sp6GCN4LS7Uk7P6AMGLDNJwEjccjdF%2BsuvYERoA%40mail.gmail.com.
Re: timesince and timeuntil - should we use python-dateutil?
I'd suggest the docs are updated with a warning relating to what's Uri's
found as it could be extremely important to someone and not highlighting it
would be misleading .
On Tuesday, 2 August 2022 at 16:31:33 UTC+1 Uri wrote:
> Hi,
>
> I created my own utility function:
>
>
>
> *from dateutil.relativedelta import relativedelta*
>
> *from django.utils.timesince import TIME_STRINGS as
> timesince_time_strings**from
> django.utils.html import avoid_wrapping*
> *from django.utils.translation import gettext, get_language*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *def timesince(d, now):delta = relativedelta(now, d)years =
> delta.yearsmonths = delta.monthsweeks = delta.days // 7days =
> delta.days - weeks * 7timesince_counts = [(years, "year"), (months,
> "month")]if (years == 0):timesince_counts.append((weeks,
> "week"))if (months == 0):timesince_counts.append((days,
> "day"))result = []for (count, name) in timesince_counts:if
> (count > 0):
> result.append(avoid_wrapping(value=timesince_time_strings[name] % {"num":
> count}))return gettext(", ").join(result)*
>
> I don't need depth>2, I don't need hours and minutes and by definition my
> function returns "" if both dates are the same. now must be bigger than d
> or else I don't know what will happen... I think you just get "" otherwise.
>
>
> https://github.com/speedy-net/speedy-net/blob/master/speedy/core/base/utils.py
>
>
> אורי
> u...@speedy.net
>
>
> On Tue, Aug 2, 2022 at 10:54 AM Carlton Gibson
> wrote:
>
>> Hey Uri.
>>
>> Historically, taking on extra dependencies isn't something we've done
>> lightly.
>> The packaging situation is a lot better these days than it was in
>> earlier years, but with the concerns about supply chain security I think
>> maintaining that position is worthwhile.
>> If we were to take on python-dateutil as a required dependency there
>> would be folks needing to go through an additional security audit in order
>> to get permission to upgrade Django. I wouldn't think two template tags
>> justifies that.
>>
>> So then, it would need to be optional.
>> But then it could just live in a third-party package.
>> (I don't think we really document it, but one could shadow/override the
>> built-in tags with the improved versions if your app was installed, I
>> guess...)
>>
>> Or that would be my initial thought. 🤔
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Tue, 2 Aug 2022 at 03:27, אורי wrote:
>>
>>> Hi,
>>>
>>> Lately I discovered some inaccuracy bugs in timesince (and timeuntil),
>>> and I created a ticket (#33879
>>> <https://code.djangoproject.com/ticket/33879>). In short, the problems
>>> are when calculating a year minus one week, 2 weeks, one day etc. and also
>>> 2 years minus one or 2 days. In all such cases, Django's implementation
>>> of timesince is inaccurate, in some cases resulting in "1 year, 12
>>> months" (for 2 years minus one or 2 days) or adding a week (for a year
>>> minus one or 2 weeks). I read the code of Django's timesince implementation
>>> and it's quite long, and I searched and found that python-dateutil already
>>> have such methods, which is possible to calculate exactly the number of
>>> days between two dates like this:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *from dateutil.relativedelta import relativedeltadiff =
>>> relativedelta(date2, date1)years = diff.yearsmonths = diff.monthsweeks =
>>> diff.days // 7days = diff.days - weeks * 7 # ("**diff.days % 7" will
>>> also work here)*
>>>
>>> This calculates exactly the number of years, months, weeks and days and
>>> not an approximation like Django's implementation. And python-dateutil is
>>> stable and I think exists even before Django. I recently started using
>>> Django's timesince function in my own website, and I like the way it's
>>> translated (currently only to English and Hebrew). Do you think it's worth
>>> using python-dateutil in the Django implementation of timesince and
>>> timeuntil?
>>>
>>> Of course, I can also implement my own version of timesince which
>>> us
Re: PivotTable or MDDataTable
Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely to answer your support query with their limited time and energy. For support, please follow the "Getting Help" page: https://docs.djangoproject.com/en/stable/faq/help/ . This will help you find people who are willing to support you, and to ask your question in a way that makes it easy for them to answer. Thanks for your understanding and all the best, Adam On Wed, Aug 10, 2022 at 10:44 PM Elias Coutinho wrote: > My friends good night. > Imagine Excel with a pivot table. > Can we build something with Kivy or KivyMD? > > I could use MDDataTable but I think it doesn't allow something like that. > > Do you have any minimalist examples? > > -- > 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/742819af-c2eb-4d7b-b62e-c48a7c48f8dcn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/742819af-c2eb-4d7b-b62e-c48a7c48f8dcn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM1-OwRF1_4A_rHR1a574sAKXFAQnJRid%3DVRos1eeaajUg%40mail.gmail.com.
Re: Django Hosting Service
Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely to answer your support query with their limited time and energy. For support, please follow the "Getting Help" page: https://docs.djangoproject.com/en/stable/faq/help/ . This will help you find people who are willing to support you, and to ask your question in a way that makes it easy for them to answer. Thanks for your understanding and all the best, Adam On Thu, Aug 11, 2022 at 8:29 PM Akshay Patwardhan < patwardhanaksh...@gmail.com> wrote: > Hi Kalidas, > > If you just want to explore how to deploy a Django application for free > without having to do all the server configurations, database setup on your > own, try Heroku. > > If you want to deploy a production grade application and need fine grain > control over the entire infrastructure, there are so many cloud hosting > platforms out there. To name a few, Digital Ocean, Linode, Azure, AWS, GCE. > > Hope this helps. > > On Fri, Aug 12, 2022 at 12:49 AM wrote: > >> Hi *Kalidas R,* >> >> >> >> Check DigitalOcean <https://www.digitalocean.com/>, if I understood >> your question correctly. >> >> >> >> Best, >> >> Teklit >> >> >> >> *From:* django-developers@googlegroups.com < >> django-developers@googlegroups.com> *On Behalf Of *Kali Raja >> *Sent:* August 11, 2022 1:10 >> *To:* Django developers (Contributions to Django itself) < >> django-developers@googlegroups.com> >> *Subject:* Django Hosting Service >> >> >> >> Hi all, >> >> >> >>Is there any specific Django hosting platform service available? >> Kindly help me to share which company provides the Django website >> application hosting service. >> >> >> >> >> >> >> >> Thanks, >> >> *Kalidas R* >> >> *Junior Developer* >> >> -- >> 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/dc28e373-e535-4199-b517-820207670d27n%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/dc28e373-e535-4199-b517-820207670d27n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> 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/002601d8adb5%24a85295a0%24f8f7c0e0%24%40gmail.com >> <https://groups.google.com/d/msgid/django-developers/002601d8adb5%24a85295a0%24f8f7c0e0%24%40gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Regards, > Akshay Patwardhan > > -- > 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/CADAjHqLsnhk8bvdbk5H3jn%3DB40RUMm3UTb_MbVYCS%2Bm1cu1UgQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CADAjHqLsnhk8bvdbk5H3jn%3DB40RUMm3UTb_MbVYCS%2Bm1cu1UgQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM1c%2BirLB%2BHY4QtP_AFJ18FUmwCBCpn6gUD2Zj3n7X522A%40mail.gmail.com.
Re: Feature request: LiveServerTestCase to store HTML source and image of the website when test case fails
Hi Kazooie LiveServerTestCase is a bit more lightweight than tools for using specific drivers. It doesn't tie into Selenium, or Playwright, or any other particular web browser library. Therefore I don't think there's going to be any way for LiveServerTestCase to know what the current page is, in order to save its contents. I think, at this time, it would be interesting to see a third party package that implements what you're suggesting, for a particular web browser library. This way you can be more specific about what you support, and how. Thanks, Adam On Sun, Aug 14, 2022 at 7:48 AM Kazooie wrote: > Hey, > > Would it be possible to add a feature to LiveServerTestCase class to take > a screenshot of the web page and store the HTML somewhere in case of test > failure? I had to recently do this for one of my projects. This can be > helpful when debugging stuff for example when test fails in CI pipeline. > > This is something Rails does by default ( > https://guides.rubyonrails.org/testing.html#screenshot-helper) and it > would be good to have this in Django as well, so users don't need to > manually code this for every project they have. Of course this would need > to also expect some default driver to be used like Chrome in Rails case. > > What are your thoughts? I'd be able to take a stab at this if this is > something that is considered useful. > > Best regards, > > Mauri Mustonen > > -- > 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/0caab9b2-4dcc-4082-9893-dd6c78c3f53cn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/0caab9b2-4dcc-4082-9893-dd6c78c3f53cn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM3sp9Xwq5vO0pmRC6Bn%2B_351N2UadhUGjH3sUoYPxeQXA%40mail.gmail.com.
Re: More user friendly delete confirmation template
> > If the object to be deleted contains many relations, the user > is overwhelmed with a list of other objects to be deleted together with the > current object. Often those objects are just internal relations the user > never heard of, and this may be unsettling. > I would argue that if the list of objects is "overwhelming" / "unsettling", then this is perhaps an indicator that the admin interface is being used beyond its intended scope. The admin is designed for site administrators, mostly developers. Yes, most projects seem to push it beyond that, but we can't make it something for all people. Collapsing the list of to-be-deleted objects could also lead to cases of accidental removal of related objects. I think it's better to err on the side of overwhelming than hiding information. On Tue, Aug 16, 2022 at 1:22 PM Danilov Maxim wrote: > Hi Jacob. > > On the one side - you can override this delete_confirmation.html and > delete_selected_confirmation.html I do it since dj 1.4 > > > > On the other side I am agree with Jacob - it can be in Django by default. > – We can add “collapsed” div to wrap with every objects list, or we > can add details/summary for that. > > > > Mit freundlichen Grüßen, > > DI Mag. Maxim Danilov > > > > +43(681)207 447 76 > > ma...@wpsoft.at > > > > *From:* django-developers@googlegroups.com [mailto: > django-developers@googlegroups.com] *On Behalf Of *Jacob Rief > *Sent:* Tuesday, August 16, 2022 1:57 PM > *To:* Django developers (Contributions to Django itself) < > django-developers@googlegroups.com> > *Subject:* More user friendly delete confirmation template > > > > Whenever a user attempts to delete an object inside the Django admin, > > a delete confirmation page is shown. If the object to be deleted contains > > many relations, the user is overwhelmed with a list of other objects to be > > deleted together with the current object. Often those objects are just > > internal relations the user never heard of, and this may be unsettling. > > > > I therefore propose to hide those related objects behind a link named > > "Show related object to delete" > > If the user clicks on that link, the complete list of objects to be > deleted is > > expanded into the confirmation page. This also prevents having to scroll > > down to the end of a potentially very long page in order to confirm the > > deletion by clicking on "Yes I'm sure". > > > > [image: Screenshot 2022-08-16 at 13.34.46.png] > > > > – 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 view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/e59f0771-cb65-4564-ace4-50a7ffd96cf6n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/e59f0771-cb65-4564-ace4-50a7ffd96cf6n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > 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/01d8b16a%24d5c5f640%248151e2c0%24%40wpsoft.at > <https://groups.google.com/d/msgid/django-developers/01d8b16a%24d5c5f640%248151e2c0%24%40wpsoft.at?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM0JL9DqgnoFSehXd5D8d4DjzEzvhrUWwbw5wqUBQdDF3Q%40mail.gmail.com.
Re: More user friendly delete confirmation template
The admin interface is not designed for such mass deletions. When deleting millions of objects, it can be necessary to paginate the deletion to avoid exhausting the resources of your database server. I don't think it's suitable for a view to try and do this. Btw in the case of sessions, use the 'clearsessions' management command: https://docs.djangoproject.com/en/4.1/ref/django-admin/#clearsessions . In the case of admin logs, I would use 'shell' with the ORM. On Tue, Aug 16, 2022 at 2:42 PM Danilov Maxim wrote: > >> Collapsing the list of to-be-deleted objects could also lead to cases > of accidental removal of related objects. I think it's better to err on the > side of overwhelming than hiding information. > > > > But sometimes It is very painful to delete whole list of sessions ( > database-backed > <https://docs.djangoproject.com/en/4.1/topics/http/sessions/#using-database-backed-sessions> > sessions) (4mlo) or Django admin logs (66mlo). > > > > > > Mit freundlichen Grüßen, > > DI Mag. Maxim Danilov > > > > +43(681)207 447 76 > > ma...@wpsoft.at > > > > *From:* 'Adam Johnson' via Django developers (Contributions to Django > itself) [mailto:django-developers@googlegroups.com] > *Sent:* Tuesday, August 16, 2022 2:55 PM > *To:* Django developers (Contributions to Django itself) < > django-developers@googlegroups.com> > *Subject:* Re: More user friendly delete confirmation template > > > > If the object to be deleted contains many relations, the user > is overwhelmed with a list of other objects to be deleted together with the > current object. Often those objects are just internal relations the user > never heard of, and this may be unsettling. > > > > I would argue that if the list of objects is "overwhelming" / > "unsettling", then this is perhaps an indicator that the admin interface is > being used beyond its intended scope. The admin is designed for site > administrators, mostly developers. Yes, most projects seem to push it > beyond that, but we can't make it something for all people. > > > > Collapsing the list of to-be-deleted objects could also lead to cases of > accidental removal of related objects. I think it's better to err on the > side of overwhelming than hiding information. > > > > On Tue, Aug 16, 2022 at 1:22 PM Danilov Maxim wrote: > > Hi Jacob. > > On the one side - you can override this delete_confirmation.html and > delete_selected_confirmation.html I do it since dj 1.4 > > > > On the other side I am agree with Jacob - it can be in Django by default. > – We can add “collapsed” div to wrap with every objects list, or we > can add details/summary for that. > > > > Mit freundlichen Grüßen, > > DI Mag. Maxim Danilov > > > > +43(681)207 447 76 > > ma...@wpsoft.at > > > > *From:* django-developers@googlegroups.com [mailto: > django-developers@googlegroups.com] *On Behalf Of *Jacob Rief > *Sent:* Tuesday, August 16, 2022 1:57 PM > *To:* Django developers (Contributions to Django itself) < > django-developers@googlegroups.com> > *Subject:* More user friendly delete confirmation template > > > > Whenever a user attempts to delete an object inside the Django admin, > > a delete confirmation page is shown. If the object to be deleted contains > > many relations, the user is overwhelmed with a list of other objects to be > > deleted together with the current object. Often those objects are just > > internal relations the user never heard of, and this may be unsettling. > > > > I therefore propose to hide those related objects behind a link named > > "Show related object to delete" > > If the user clicks on that link, the complete list of objects to be > deleted is > > expanded into the confirmation page. This also prevents having to scroll > > down to the end of a potentially very long page in order to confirm the > > deletion by clicking on "Yes I'm sure". > > > > [image: Screenshot 2022-08-16 at 13.34.46.png] > > > > – 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 view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/e59f0771-cb65-4564-ace4-50a7ffd96cf6n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/e59f0771-cb65-4564-ace4-50a7ffd96cf6n%4
Re: Allow for strict mode in templates
Django logs warnings for missing variables. I believe this logging was added since that ticket was closed. I recently wrote a blog post with some techniques you can use to hook into this logging and turn those errors into exceptions: https://adamj.eu/tech/2022/03/30/how-to-make-django-error-for-undefined-template-variables/ . I hope that helps. On Sat, Aug 20, 2022 at 2:34 PM 'Michael Hübner' via Django developers (Contributions to Django itself) wrote: > I was struggeling with a get query that just wouldn't throw any > exceptions. Then I stubled about this: > > https://code.djangoproject.com/ticket/11909 > > I'm so sorry about the rude request in there, but it would be really > helpful to allow for a "strict mode" in templates where errors get thrown > to help debug issues. > > > -- > 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/0b926630-6832-48a0-8377-c74d93c55a83n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/0b926630-6832-48a0-8377-c74d93c55a83n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM12%3DHzrpojjZNerPu7bwbTcCPVUCQjXM4tViP6rb5A_0w%40mail.gmail.com.
transaction.on_commit() proposal
Hi I just wrote a blog post on a late-binding bug that can occur with using transaction.on_commit() with a function or lambda within a loop. THe post shows how using functools.partial() solves this. See the post here: https://adamj.eu/tech/2022/08/22/use-partial-with-djangos-transaction-on-commit/ I propose that transaction.on_commit() be modified to take args and kwargs to pass to the callback function. This would mean it effectively constructs a partial() "under the hood": transaction.on_commit(send_mail, subject=f"...", recipient_list=[user.email], ...) I think this would be simpler than asking developers to beware of the late-binding problem and use partial(), always or when appropriate. This change would make transaction.on_commit() similar to Python's atexit.register(), which also takes a callback to run at a later point, and optional args/kwargs to pass it: https://docs.python.org/3.10/library/atexit.html#atexit.register The only backwards-compatibility concern I can see is the `using` argument, which would not be passed to the underlying function. I don't see this as a huge concern, since it would be the only argument that isn't passed through, and there doesn't seem to be any reason to add further arguments. Users who need to pass a kwarg called 'using' could always construct a partial() themselves. Thoughts? Adam -- 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/CAMyDDM2OQoj3mV4pHuo8OB%2BLM6xpZdLQdSTyaGR%2B1m5oPg-C7Q%40mail.gmail.com.
Re: transaction.on_commit() proposal
I'd also be okay with a docs change, although this wouldn't help avoid late-binding bugs quite so much. On Mon, Aug 22, 2022 at 1:51 PM Carlton Gibson wrote: > Related ticket from this weekend, suggesting a docs change: > https://code.djangoproject.com/ticket/33939 > > On Mon, 22 Aug 2022 at 14:11, 'Adam Johnson' via Django developers > (Contributions to Django itself) > wrote: > >> Hi >> >> I just wrote a blog post on a late-binding bug that can occur with using >> transaction.on_commit() with a function or lambda within a loop. THe post >> shows how using functools.partial() solves this. See the post here: >> https://adamj.eu/tech/2022/08/22/use-partial-with-djangos-transaction-on-commit/ >> >> I propose that transaction.on_commit() be modified to take args and >> kwargs to pass to the callback function. This would mean it effectively >> constructs a partial() "under the hood": >> >> transaction.on_commit(send_mail, subject=f"...", >> recipient_list=[user.email], ...) >> >> I think this would be simpler than asking developers to beware of the >> late-binding problem and use partial(), always or when appropriate. >> >> This change would make transaction.on_commit() similar to Python's >> atexit.register(), which also takes a callback to run at a later point, and >> optional args/kwargs to pass it: >> https://docs.python.org/3.10/library/atexit.html#atexit.register >> >> The only backwards-compatibility concern I can see is the `using` >> argument, which would not be passed to the underlying function. I don't see >> this as a huge concern, since it would be the only argument that isn't >> passed through, and there doesn't seem to be any reason to add further >> arguments. Users who need to pass a kwarg called 'using' could always >> construct a partial() themselves. >> >> Thoughts? >> >> Adam >> >> -- >> 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/CAMyDDM2OQoj3mV4pHuo8OB%2BLM6xpZdLQdSTyaGR%2B1m5oPg-C7Q%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAMyDDM2OQoj3mV4pHuo8OB%2BLM6xpZdLQdSTyaGR%2B1m5oPg-C7Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAJwKpyTBmLTR8cLbOMWFmm-y47jH1Jki48BF57cvM%3DKPpjNGHw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAJwKpyTBmLTR8cLbOMWFmm-y47jH1Jki48BF57cvM%3DKPpjNGHw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM354E0mQg8KAnrmzoJe7nZ7JyHGXgjppGXde-5mMfzqUg%40mail.gmail.com.
Re: Feature Request: get_default_backend() in django.template.Engine
Improving the docs sounds good.
I think it would also be worth renaming engines to backends, and
EngineHandler to BackendHandler, or similar. Yes it would require a
deprecation cycle, but I also imagine 99% of projects would be unaffected.
On Tue, Aug 23, 2022 at 8:39 PM Peter Thomassen wrote:
> Hi Carlton,
>
> On Mon, Aug 22, 2022 at 6:21 AM Carlton Gibson
> wrote:
> > The current get_default() behaviour was only added to allow folks
> manually creating `Template("My String")` instances to continue to operate
> with multiple Django backends defined (#27359) — the initial assumption
> there was that anonymous backend usage wouldn't be supported, i.e. that
> folks would do `engines["django"]` to get a specific backend. Could you
> use that?
>
> Yeah, that works! Thank you for the hint.
>
> The docs mention this functionality with the wrong wording, which is why I
> was not aware of this functionality:
>
> > Template engines are available in django.template.engines:
> >
> > from django.template import engines
> >
> > django_engine = engines['django']
> > template = django_engine.from_string("Hello {{ name }}!")
> --
> https://docs.djangoproject.com/en/4.0/topics/templates/#django.template.loader.engines
>
> This is not accurate: `engines` ironically holds the template backends,
> not the engines, and each engine can be retrieved by calling .engine (such
> as engines['django'].engine).
>
> In general, the docs are very inconsistent in this regard and use the
> terms "backend" and "engine" pretty much interchangeably. The code is
> naturally more strict, but the iterable holding the backends nevertheless
> is called `engines`.
>
> If people feel this is a correct assessment, I can try improving on the
> wording.
>
> Thanks,
> Peter
>
> --
> https://desec.io/
>
> --
> 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/5232c741-8410-1bcc-62d0-3ee942b25ea2%40desec.io
> .
>
--
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/CAMyDDM2uNBpouXsHkN2ymZxOejSK2U%3DDaaRVRKwPTKdeQCT3GQ%40mail.gmail.com.
Re: Named Groups for Enumeration Types
Hi Steven
I agree that grouped choices would be nice to support in the enum types.
Thank you for taking a look at this.
I'm not sure about either of your proposed syntaxes. They both seem error
prone and unclear to me. I propose instead using a separate grouping
attribute:
class Media(models.TextChoices):
VINYL = "vinyl"
CD = "cd", "CD"
VHS_TAPE = "vhs", "VHS Tape"
DVD = "dvd", _("DVD")
UNKNOWN = "unknown"
groups = {
"Audio": [VINYL, CD],
"Video": [VHS_TAPE, DVD],
"Unknown": [UNKNOWN]
}
Relatedly, there is pre-pandemic ticket and PR to support dictionaries in
Field.choices: https://github.com/django/django/pull/12449 . It could make
sense to look at that first, if you'd like to. Enumeration type grouping is
kinda orthogonal, but if dict support was added, the "choices" property
could use it.
Thanks,
Adam
On Wed, Aug 3, 2022 at 2:47 AM Steven Johnson
wrote:
> Hello all,
>
> In my project I recently wanted to group choices, and have gotten used to
> the Enumeration Types Django provides. I noticed Django currently does not
> support named groups for these.
>
> So, I've implemented them in two ways:
> Option A) Ugly, but simple changes to Django
>
> class Media(models.TextChoices):
> _named_group1 = "Audio"
> VINYL = "vinyl"
> CD = "cd", "CD"
> _named_group2 = "Video"
> VHS_TAPE = "vhs", "VHS Tape"
> DVD = "dvd", _("DVD")
> _named_group3 = None
> UNKNOWN = "unknown"
>
> Option B) Pretty, but complex changes to Django
>
> class Media(models.TextChoices):
> class Audio(models.TextChoices):
> VINYL = "vinyl"
> CD = "cd", "CD"
>
> class Video(models.TextChoices):
> VHS_TAPE = "vhs", "VHS Tape"
> DVD = "dvd", _("DVD")
>
> UNKNOWN = "unknown"
>
> Does anyone have better ideas to implement named groups here? Would one of
> these implementations be useful for Django?
> Below are links to personal pull requests to see potential patches. The
> pull requests include tests and documentation.
>
> GitHub links:
> * https://github.com/shjohnson-pi/django/pull/1 (Pretty, complex)
> * https://github.com/shjohnson-pi/django/pull/2 (Ugly, simple)
> Relevant docs:
> *
> https://docs.djangoproject.com/en/4.1/ref/models/fields/#field-choices-named-groups
> *
> https://docs.djangoproject.com/en/4.1/ref/models/fields/#enumeration-types
>
> Thank you,
> Steven H Johnson
>
> --
> 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/7d66f6a9-4056-4e2e-ade2-8175994ebd20n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/7d66f6a9-4056-4e2e-ade2-8175994ebd20n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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%2Buy3-x29983pBjMEcZfp26O5tN5MAQBMyxDUaG-UyFA%40mail.gmail.com.
Re: Change `to_python` and `to_url` to be class methods on path converters
I can see the appeal of allowing you to have fewer classes, but I don't
think that's a good thing in itself. Keeping responsibilities separate
("convert slugs to/from URL's" versus "be a slug") is a generally desirable
property.
This change would also complicate the URL parsing process: it would need to
check whether the methods are class or instance level, and instantiate the
converter or not. We wouldn't want to force all converters to move to use
classmethods as that would be a backwards incompatible change, requiring a
deprecation cycle.
On Wed, Aug 24, 2022 at 7:35 PM Petter friberg
wrote:
> Hi,
>
> I ran in to the situation of wanting `to_python` and `to_url` be decorated
> with `@classmethod` to avoid having to declare an additional (kind of
> no-op) class with those 2 methods.
>
> Given that I have a couple of custom python data structures that can be
> encoded into path params, it would be slightly more cleaner if my custom
> class(es) would be the ones declaring `def to_python` and `def to_url` to
> comply with the path converter interface. Rather than having some
> additional `class Converter`.
>
> Below follows an invented example, where I pretend to have some product
> slug composed of a slugged name and integer code. Imagine seeing something
> like “white-socks-123456789” in a URL.
>
> ```
> class Slug:
> regex = r".+"
>
> def __init__(self, slugged_name, sku):
> self.slugged_name = slugged_name
> self.sku = sku
>
> @classmethod
> def to_python(cls, value):
> name, _, sku = value.rpartition("-")
> if not name:
> raise ValueError("invalid name segment")
>
> try:
> sku = int(sku)
> except ValueError as exc:
> raise ValueError("sku needs to be a number") from exc
>
> return cls(name, sku)
>
> @classmethod
> def to_url(cls, slug):
> return f"{slug.slugged_name}-{slug.sku}"
>
>
> register_converter(Slug, "my-slug")
> ```
>
> Could changing the converter interface be something to consider?
> At least I couldn’t see any obvious problems with expecting these 2
> methods as `@classmethod` (or even `@staticmethod`?) instead. But I could
> very well be missing something.
>
> Thanks!
> Petter
>
> --
> 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/a43092e4-34a1-403a-beef-a2c4cac710ebn%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/a43092e4-34a1-403a-beef-a2c4cac710ebn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMyDDM3PTv0Bre7aBDWW%3DFx1j3Az2GihPBqJ3tetKjf3cXtVkA%40mail.gmail.com.
Ticket #32118 Add field for 4-bytes floats (RealField/SmallFloatField)
Hi! I would like to provide an example of why this field is needed. In PostgreSQL, a floating point literal like 4.6 has type decimal, not binary floating point (see SELECT pg_typeof(4.6)). When comparing binary floating point values to decimals, the decimal is converted to double precision binary floating point value. This make FloatField work. But if you have real/float4 fields and you compare them to decimal value, it doesn't work. Here is an example, with a workaround. in bar/models.py from django.db import models from django.db.models import FloatField class RealField(FloatField): def db_type(self, connection): return 'real' class Thing(models.Model): score = RealField(null=False) and now in shell: from django.db.models import Value from django.db.models.functions import Cast from bar.models import RealField, Thing Thing(score=4.6).save() Thing.objects.all()[0].score 4.6 Thing.objects.filter(score=4.6).first() None str(Thing.objects.filter(score=4.6).query) SELECT "bar_thing"."id", "bar_thing"."score" FROM "bar_thing" WHERE "bar_thing"."score" = 4.6 Thing.objects.filter(score=Cast(Value(4.6), RealField())).first() str(Thing.objects.filter(score=Cast(Value(4.6), RealField())).query) SELECT "bar_thing"."id", "bar_thing"."score" FROM "bar_thing" WHERE "bar_thing"."score" = (4.6)::real Can Django have a RealField that automatically does the cast? -- <https://swampup.jfrog.com/?utm_source=email&utm_medium=footer&utm_campaign=emea_sales&utm_term=city-tour-22> -- 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/068b4121-d28c-4bd7-997e-7fc5d499119en%40googlegroups.com.
Re: A generic cache decorator around low level cache api
I'm not sure I quite understand your proposal. Are you suggesting a decorator that caches the results of every queryset that is resolved within the decorated function? If so, I'm not sure how useful it would be. First, if a single query is problematic, there’s normally a way to optimize it within the database - for example, a materialized view allows you to “cache” query results and recompute them in the background. Second, QuerySets are lazy, so it could be surprising to decorate a function that returns a QuerySet that is not yet resolved. On Wed, Aug 24, 2022 at 3:49 PM suayip uzulmez wrote: > Usually, I need to construct a simple cache pipeline to optimize database > access using low-level cache API (django.core.cache). > > I think we could use a decorator as such to ease this process: > > cached_context(key, *, timeout, cache) > > I know higher-level utilities exist such as cache_page, however I think > the decorator above provides more granularity over what to cache. For > example, I usually need such decorator in model methods where I do some > database aggregation operations based on the instance. > > What do you think? > > -- > 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/facbcfa8-2404-4dc6-b56d-eb0f25ba491cn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/facbcfa8-2404-4dc6-b56d-eb0f25ba491cn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM3jh_tHOLfxggk68114kSS3qk3i0vBsd-kvqcp1WXCr7Q%40mail.gmail.com.
Add support for IDNA 2008
Hi, I'm starting this discussion following ticket #33968 <https://code.djangoproject.com/ticket/33968> recommendation in comment. Currently the punycode <https://github.com/django/django/blob/e64919ae54933ef4840f0e27e51d9fcfd55ecf4b/django/utils/encoding.py#L212> method is converting domain names from Unicode to ASCII using the deprecated IDNA 2003 standard. As suggested in the ticket, the method should use the idna <https://pypi.org/project/idna/> package that is fully compliant with the latest IDNA 2008 standard. Ticket comment points that adding a new dependency is problematic, however, in most case, someone using Django will end up with this dependency anyway as it is widely used. Django GeoIP2 contrib uses it for instance. Best regards, Julien -- 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/d4331b21-d9e8-4647-aa1f-357b00fb0125n%40googlegroups.com.
Re: Add support for IDNA 2008
Some data... The idna package has ~9M downloads a day ( https://pypistats.org/packages/idna ) compared with Django's ~350k ( https://pypistats.org/packages/django ). However it has 191 GitHub stars ( https://github.com/kjd/idna ) compared to Django's 66k ( https://github.com/django/django ). I imagine most idna installs are from popular packages depending on it: at least requests, and twisted do. Most people probably don't care about complete domain validation (until they do). To me, it seems like a reasonable dependency for Django to adopt, given so much of the ecosystem uses it. But I don't think there's much evidence of demand. I found one other ticket mentioning idna, and this was with an extended regex, not the package ( https://code.djangoproject.com/ticket/18119 , seems stale, maybe closeable? ). I'd suggest at this point: implement idna validators in a third party package, do some advocacy for why projects would need it, and show some adoption. This would make the case for Django itself stronger. On Thu, Sep 1, 2022 at 4:18 PM 'Julien Bernard' via Django developers (Contributions to Django itself) wrote: > Hi, > I'm starting this discussion following ticket #33968 > <https://code.djangoproject.com/ticket/33968> recommendation in comment. > Currently the punycode > <https://github.com/django/django/blob/e64919ae54933ef4840f0e27e51d9fcfd55ecf4b/django/utils/encoding.py#L212> > method is converting domain names from Unicode to ASCII using the > deprecated IDNA 2003 standard. > As suggested in the ticket, the method should use the idna > <https://pypi.org/project/idna/> package that is fully compliant with the > latest IDNA 2008 standard. > Ticket comment points that adding a new dependency is problematic, > however, in most case, someone using Django will end up with this > dependency anyway as it is widely used. Django GeoIP2 contrib uses it for > instance. > Best regards, > Julien > > -- > 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/d4331b21-d9e8-4647-aa1f-357b00fb0125n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/d4331b21-d9e8-4647-aa1f-357b00fb0125n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM263vJfcYe1ifPu0ACZX6RFh-acoRkp-LWMxRC-0r1THQ%40mail.gmail.com.
Re: Add support for IDNA 2008
Thanks Adam. The ticket was targetting EmailValidator but the punycode method is used at more places in Django core. If you look for Unicode characters support in email addresses in tickets you will get more than looking for IDN but indeed the demand may not be that much. This is a vicious circle, IDNs and especially EAIs are not widely used because of the poor support in software and the lack of compliance with the latest version. Regards, Julien Le jeudi 1 septembre 2022 à 13:33:29 UTC-4, Adam Johnson a écrit : > Some data... > > The idna package has ~9M downloads a day ( > https://pypistats.org/packages/idna ) compared with Django's ~350k ( > https://pypistats.org/packages/django ). > > However it has 191 GitHub stars ( https://github.com/kjd/idna ) compared > to Django's 66k ( https://github.com/django/django ). > > I imagine most idna installs are from popular packages depending on it: at > least requests, and twisted do. Most people probably don't care about > complete domain validation (until they do). To me, it seems like a > reasonable dependency for Django to adopt, given so much of the ecosystem > uses it. > > But I don't think there's much evidence of demand. I found one other > ticket mentioning idna, and this was with an extended regex, not the > package ( https://code.djangoproject.com/ticket/18119 , seems stale, > maybe closeable? ). > > I'd suggest at this point: implement idna validators in a third party > package, do some advocacy for why projects would need it, and show some > adoption. This would make the case for Django itself stronger. > > On Thu, Sep 1, 2022 at 4:18 PM 'Julien Bernard' via Django developers > (Contributions to Django itself) wrote: > >> Hi, >> I'm starting this discussion following ticket #33968 >> <https://code.djangoproject.com/ticket/33968> recommendation in comment. >> Currently the punycode >> <https://github.com/django/django/blob/e64919ae54933ef4840f0e27e51d9fcfd55ecf4b/django/utils/encoding.py#L212> >> >> method is converting domain names from Unicode to ASCII using the >> deprecated IDNA 2003 standard. >> As suggested in the ticket, the method should use the idna >> <https://pypi.org/project/idna/> package that is fully compliant with >> the latest IDNA 2008 standard. >> Ticket comment points that adding a new dependency is problematic, >> however, in most case, someone using Django will end up with this >> dependency anyway as it is widely used. Django GeoIP2 contrib uses it for >> instance. >> Best regards, >> Julien >> >> -- >> 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-develop...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/d4331b21-d9e8-4647-aa1f-357b00fb0125n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/d4331b21-d9e8-4647-aa1f-357b00fb0125n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/90f58142-7808-4136-a06d-8ba1352857c7n%40googlegroups.com.
Re: Add support for IDNA 2008
Thanks Carlton. This makes total sense to keep things simple and avoid bringing another dependency in the context of validation, providing that you won't prevent valid URLs to be accepted. That's where it can be tricky but it seems reasonable to think that the current domain validation is too permissive from what I saw. But the punycode method is also used in other places where it is more "critical" than a validator: - Urlizer - CachedDnsName - email sending. The need for the idna package should be evaluated regarding those usages rather than the validation. Best regards, Julien Le dimanche 4 septembre 2022 à 05:16:19 UTC-4, carlton...@gmail.com a écrit : > Hi Julian. > > We've had several tickets and discussions surrounding how far e.g. > URLValidator needs to match all valid URLs. The conclusion we've come to > (which is always provisional) is that actually we **don't** want such match > all valid (according to the relevant RFC and such) input. Rather, we'd > prefer a simpler implementation — that's realistically maintainable for us > — that captures the 95% case, and then ask users to implement a custom > validator if they need more. This seems like a happy compromise. > > I hope that makes sense. > > I agree with Adam here that a third-party package is the immediate way > forward here. If it shows a lot of demand then it's always open to revisit > whether that should be included in Django itself. (Taking on an extra > dependency for a small subset of users is always going to be up for debate > — it's not a blocker per se, but it does need weighing...) > > Kind Regards, > > Carlton > > On Fri, 2 Sept 2022 at 17:32, 'Julien Bernard' via Django developers > (Contributions to Django itself) wrote: > >> Thanks Adam. >> The ticket was targetting EmailValidator but the punycode method is used >> at more places in Django core. >> If you look for Unicode characters support in email addresses in tickets >> you will get more than looking for IDN but indeed the demand may not be >> that much. >> This is a vicious circle, IDNs and especially EAIs are not widely used >> because of the poor support in software and the lack of compliance with the >> latest version. >> Regards, >> Julien >> >> >> Le jeudi 1 septembre 2022 à 13:33:29 UTC-4, Adam Johnson a écrit : >> >>> Some data... >>> >>> The idna package has ~9M downloads a day ( >>> https://pypistats.org/packages/idna ) compared with Django's ~350k ( >>> https://pypistats.org/packages/django ). >>> >>> However it has 191 GitHub stars ( https://github.com/kjd/idna ) >>> compared to Django's 66k ( https://github.com/django/django ). >>> >>> I imagine most idna installs are from popular packages depending on it: >>> at least requests, and twisted do. Most people probably don't care about >>> complete domain validation (until they do). To me, it seems like a >>> reasonable dependency for Django to adopt, given so much of the ecosystem >>> uses it. >>> >>> But I don't think there's much evidence of demand. I found one other >>> ticket mentioning idna, and this was with an extended regex, not the >>> package ( https://code.djangoproject.com/ticket/18119 , seems stale, >>> maybe closeable? ). >>> >>> I'd suggest at this point: implement idna validators in a third party >>> package, do some advocacy for why projects would need it, and show some >>> adoption. This would make the case for Django itself stronger. >>> >>> On Thu, Sep 1, 2022 at 4:18 PM 'Julien Bernard' via Django developers >>> (Contributions to Django itself) wrote: >>> >>>> Hi, >>>> I'm starting this discussion following ticket #33968 >>>> <https://code.djangoproject.com/ticket/33968> recommendation in >>>> comment. >>>> Currently the punycode >>>> <https://github.com/django/django/blob/e64919ae54933ef4840f0e27e51d9fcfd55ecf4b/django/utils/encoding.py#L212> >>>> >>>> method is converting domain names from Unicode to ASCII using the >>>> deprecated IDNA 2003 standard. >>>> As suggested in the ticket, the method should use the idna >>>> <https://pypi.org/project/idna/> package that is fully compliant with >>>> the latest IDNA 2008 standard. >>>> Ticket comment points that adding a new dependency is problematic, >>>> however, in most case, some
Re: Add support for IDNA 2008
Hi Carlton, IDNA 2008 made some changes in the valid or invalid IDNs and some differences in the ways some characters are transformed in Punycode compared to IDNA 2003 for multiple reasons. A difference that is often used as an example is the german 'ß' character. In IDNA 2003 it is transformed into 'ss' while it is converted into Punycode in IDNA 2008. It means that, depending on the standard that is implemented, you may reach totally different domains with the same IDN, which may lead to security issues. For example, the URL https://fuß.standcore.com/ would be https://fuss.standcore.com/ with IDNA 2003 and https://xn--fu-hia.standcore.com/ with IDNA 2008. This is only a very brief insight, for further quick readings, https://www.unicode.org/faq/idn.html is quite informative too. Best regards, Julien Le mardi 6 septembre 2022 à 14:39:49 UTC-4, carlton...@gmail.com a écrit : > Hey Julian. > > What's maybe missing is some concrete cases. "This conversion should be > made IDNA 2008 compliant." — OK, but what does that buy us? > > Maybe the idna package is OK... It's widely depended on already — I got it > for free yesterday installing httpx in a project — and packaging isn't what > it was... — but **if** we take on an extra dependency it needs to be for a > clear gain. > > Likely (still) a proof-of-concept at least showing what's added (as a > separate package? 🤔) is the easiest way forward? > > Others may yet agree that this is something needed. > > Kind Regards, > > Carlton > > On Tue, 6 Sept 2022 at 20:23, 'Julien Bernard' via Django developers > (Contributions to Django itself) wrote: > >> Thanks Carlton. >> >> This makes total sense to keep things simple and avoid bringing another >> dependency in the context of validation, providing that you won't prevent >> valid URLs to be accepted. That's where it can be tricky but it seems >> reasonable to think that the current domain validation is too permissive >> from what I saw. >> But the punycode method is also used in other places where it is more >> "critical" than a validator: >> >>- Urlizer >>- CachedDnsName >>- email sending. >> >> The need for the idna package should be evaluated regarding those usages >> rather than the validation. >> >> Best regards, >> Julien >> >> Le dimanche 4 septembre 2022 à 05:16:19 UTC-4, carlton...@gmail.com a >> écrit : >> >>> Hi Julian. >>> >>> We've had several tickets and discussions surrounding how far e.g. >>> URLValidator needs to match all valid URLs. The conclusion we've come to >>> (which is always provisional) is that actually we **don't** want such match >>> all valid (according to the relevant RFC and such) input. Rather, we'd >>> prefer a simpler implementation — that's realistically maintainable for us >>> — that captures the 95% case, and then ask users to implement a custom >>> validator if they need more. This seems like a happy compromise. >>> >>> I hope that makes sense. >>> >>> I agree with Adam here that a third-party package is the immediate way >>> forward here. If it shows a lot of demand then it's always open to revisit >>> whether that should be included in Django itself. (Taking on an extra >>> dependency for a small subset of users is always going to be up for debate >>> — it's not a blocker per se, but it does need weighing...) >>> >>> Kind Regards, >>> >>> Carlton >>> >>> On Fri, 2 Sept 2022 at 17:32, 'Julien Bernard' via Django developers >>> (Contributions to Django itself) wrote: >>> >>>> Thanks Adam. >>>> The ticket was targetting EmailValidator but the punycode method is >>>> used at more places in Django core. >>>> If you look for Unicode characters support in email addresses in >>>> tickets you will get more than looking for IDN but indeed the demand may >>>> not be that much. >>>> This is a vicious circle, IDNs and especially EAIs are not widely used >>>> because of the poor support in software and the lack of compliance with >>>> the >>>> latest version. >>>> Regards, >>>> Julien >>>> >>>> >>>> Le jeudi 1 septembre 2022 à 13:33:29 UTC-4, Adam Johnson a écrit : >>>> >>>>> Some data... >>>>> >>>>> The idna package has ~9M downloads a
Re: Lookups
Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely to answer your support query with their limited time and energy. For support, please follow the "Getting Help" page: https://docs.djangoproject.com/en/stable/faq/help/ . This will help you find people who are willing to support you, and to ask your question in a way that makes it easy for them to answer. Thanks for your understanding and all the best, Adam On Thu, Sep 8, 2022 at 3:15 PM Bhuvnesh Sharma wrote: > Can anyone explain me the difference between lookups and related lookups? > > -- > 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/16ebb8e9-166e-4974-8069-2005345eebfan%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/16ebb8e9-166e-4974-8069-2005345eebfan%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM2E0QoquZe5wd7T9eanTNLqWdW40NvZF%3DPLg6nW2ivH0w%40mail.gmail.com.
Re: Django timing
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.
For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you
find people who are willing to support you, and to ask your question in a
way that makes it easy for them to answer.
Thanks for your understanding and all the best,
Adam
On Fri, Sep 9, 2022 at 2:48 PM Bhuvnesh Sharma
wrote:
> Hi,
> if you are using templates then you can simply write:
>
> {{message.created|timesince}} ago
>
> where created is a field of message storing the date and time when the
> message was created.
>
> created = models.DateTimeField(auto_now_add=True)
>
>
> On Friday, September 9, 2022 at 7:11:00 PM UTC+5:30 pmicha...@gmail.com
> wrote:
>
>> Hello. I was developing an instagram clone website but got a problem when
>> I wanted to add timing to the post, timing like "2 minutes ago", "just now"
>> etc. I searched through the internet I couldn't get the right solution (I
>> don't know if there is solution for it yet). Then I decided to go on a
>> journey of solving the problem myself, which I did and I will like to share
>> the codes with the community for review and improvements (if any). I have
>> no idea where to do that, I will love to get a reply soon because I cannot
>> wait to contribute to django. I am also ready to give full detail of the
>> code and how to use.
>
> --
> 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/664a2283-be6d-49db-9316-7940b013297fn%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/664a2283-be6d-49db-9316-7940b013297fn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMyDDM0Gp5QTVrf%2BNySqi7aPDsZ-%3DK9cBNKScMWrYWxFvWe0rQ%40mail.gmail.com.
Re: Add support for IDNA 2008
Hi Carlton,
Le mardi 13 septembre 2022 à 07:17:31 UTC-4, carlton...@gmail.com a écrit :
> Hi Julien.
>
> I didn't get a canonical answer from the security team yet, but it may be
> that we can make the idna an optional dependency quite easily. I already
> have it installed in my dev environment, for instance, coming from selenium
> and requests.
>
> From the package docs: https://pypi.org/project/idna/
>
>You may use the codec encoding and decoding methods using
> the idna.codec module:
>>>> import idna.codec
>>>> print('домен.испытание'.encode('idna'))
>b'xn--d1acufc.xn--80akhbyknj4f'
>
> So "use if installed" (catching the ImportError if not) would look
> feasible. (The usage in the punycode helper is just `domain.encode("idna")`
> which matches this example already.)
>
That's great news! Thanks.
>
> Would you fancy looking a PR around that?
>
Yes, no problem.
>
> We'd need *some* tests for both the installed and not-installed cases,
> ideally showing the difference. I didn't immediately have success with your
> https://fuss.standcore.com/ example:
>
> % python
> Python 3.10.6 (v3.10.6:9c7b4bd164, Aug 1 2022, 17:13:48) [Clang
> 13.0.0 (clang-1300.0.29.30)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> print('https://fuß.standcore.com/'.encode('idna'))
> b'https://fuss.standcore.com/'
> >>> import idna.codec
> >>> print('https://fuß.standcore.com/'.encode('idna'))
> b'https://fuss.standcore.com/' # Was expecting
> https://xn--fu-hia.standcore.com/ from discussion 🤔
> >>> import idna
> >>> idna.encode('https://fuß.standcore.com/')
> Traceback (most recent call last):
> File "", line 1, in
> File
> "/Users/carlton/Envs/django/lib/python3.10/site-packages/idna/core.py",
> line 357, in encode
> s = alabel(label)
> File
> "/Users/carlton/Envs/django/lib/python3.10/site-packages/idna/core.py",
> line 269, in alabel
> check_label(label)
> File
> "/Users/carlton/Envs/django/lib/python3.10/site-packages/idna/core.py",
> line 250, in check_label
> raise InvalidCodepoint('Codepoint {} at position {} of {} not
> allowed'.format(_unot(cp_value), pos+1, repr(label)))
> idna.core.InvalidCodepoint: Codepoint U+003A at position 6 of
> 'https://fuß' not allowed
>
I was not able to get .encode('idna') to work either. I reported this issue
https://github.com/kjd/idna/issues/128 to check why this is not working as
expected.
For the last part, idna works with labels or domains, so you would have to
provide only the domain to the encode method:
% python
Python 3.10.7 (main, Sep 6 2022, 21:22:27) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import idna
>>> idna.encode('fuß.standcore.com')
b'xn--fu-hia.standcore.com'
Best regards,
Julien
>
> Possibly there's some objection to such a change, but I'm struggling to
> imagine it short of concrete cases...
>
> Thanks!
>
> Kind Regards,
>
> Carlton
>
>
>
> On Wednesday, 7 September 2022 at 08:18:13 UTC+2 Carlton Gibson wrote:
>
>> Hey Julien.
>>
>> Thanks, OK... 📖
>>
>> The Python docs have it
>> <https://docs.python.org/3.10/library/codecs.html#python-specific-encodings>
>> :
>>
>> > If you need the IDNA 2008 standard from *RFC 5891*
>> <https://tools.ietf.org/html/rfc5891.html> and *RFC 5895*
>> <https://tools.ietf.org/html/rfc5895.html>, use the third-party idna
>> module <https://pypi.org/project/idna/>.
>>
>> So the question is do we **need** the newer standard?
>>
>> I will have a read of the various resources here, and I'll also ask the
>> Django Security Team if they have any thoughts.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Tue, 6 Sept 2022 at 23:03, 'Julien Bernard' via Django developers
>> (Contributions to Django itself) wrote:
>>
>>> Hi Carlton,
>>>
>>> IDNA 2008 made some changes in the valid or invalid IDNs and some
>>> differences in the ways some characters are transformed in Punycode
>>> compared to IDNA 2003 for multiple reasons.
>>> A differe
Re: Proposal: Make it so when getting an image's dimensions, EXIF orientation is considered
I’m +1 to making this change. Incorrect orientation is frustrating and this is why browsers changed to always consider it (by default). You're right that the web default is to consider EXIF orientation data, controllable with the image-orientation CSS property: https://developer.mozilla.org/en-US/docs/Web/CSS/image-orientation . (FYI, link to MDN in future, it's a more neutral/universal source than Chrome docs. MDN shows compat in all browsers, and Chrome implements a lot of unique features). On Sat, Sep 24, 2022 at 5:51 PM Adam Taylor wrote: > Following the advice of David Sanders and Mariusz Felisiak, I'm coming > here with my proposal rather than continuing on with the ticket system (see > ticket > #34035 <https://code.djangoproject.com/ticket/34035>). > > I understand the reluctance to make this change. However, things change > with web browsers and I believe web frameworks should make changes to stay > in line with the web browsers. It used to be less common for web browsers > to consider EXIF orientation, but now it's the standard. ImageField being > able to save the image dimensions to another field is very useful but for > my use case it's broken because it doesn't consider EXIF orientation so > there are cases where the dimensions are the opposite of what they should > be. I highly doubt I'm alone in this. Maybe there should be a setting that > can be passed into ImageField to avoid breaking existing projects. I > definitely think this should be part of Django rather than having the > developers need to add this logic to each of their Django projects that > need it. > > Thoughts? > > -- > 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/c51cfad1-df74-446a-a341-53a007a9ae9fn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/c51cfad1-df74-446a-a341-53a007a9ae9fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM1OXhAv%3DvNuha18Ssp0fJFWCfVgDxGK4gYLoKDH%3D5Nqcw%40mail.gmail.com.
Re: Proposal: Make it so when getting an image's dimensions, EXIF orientation is considered
To have extra properties, we'd need to add extra database fields. It would be somewhat wasteful to add them to all ImageFields when few users will care about the difference. On Mon, Sep 26, 2022 at 10:28 AM David Sanders wrote: > Actually might as well throw out one idea, feel free to discard: > > Keep width and height as-is and add 2 additional properties for jpg: > `photo_width` and `photo_height` (or named something more suitable) > > This way it stays inline with other image viewing/editing software which > still reports the width and height as is read from the image with the > rotation as separate meta-data. (Eg I did a cursory look with Gimp & > Preview on mac) > > On Mon, 26 Sept 2022 at 19:20, David Sanders > wrote: > >> Coincidence I was also just reading up image-orientation… I didn't >> realise that it's the default behaviour now to orient. >> >> I guess it's a question of whether/how to be backwards compatible? >> > -- > 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/CADyZw-5mR87oKsDVnyLFwuftxY3As0%3Dz9JXydbSu2-Lvni-F7g%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CADyZw-5mR87oKsDVnyLFwuftxY3As0%3Dz9JXydbSu2-Lvni-F7g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM1Lwt0sGLtfb3yY-H_341TiJN-Vd1%2BaFNV6aHvwkZQNkg%40mail.gmail.com.
Re: Regarding Django forms
Hi! I think you've found the wrong mailing list for this post (django-developers). This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely to answer your support query with their limited time and energy. Please also avoid posting to multiple mailing lists at once. For support, please follow the "Getting Help" page: https://docs.djangoproject.com/en/stable/faq/help/ . This will help you find people who are willing to support you, and to ask your question in a way that makes it easy for them to answer. Thanks for your understanding and all the best, Adam On Fri, Sep 23, 2022 at 5:31 PM Kiet Lam wrote: > Why don't you also use the context and pass in an array to be rendered at > the htm? > > There are too many repeating and hard code elements that could have been > done with a single foreach statement. > > On Sat, Sep 24, 2022 at 2:27 AM Kiet Lam wrote: > >> Hi Nishant, >> Yes. I would stick to using Django forms. It has a lot of inbuilt >> security protection that is easily implemented at the front end like CSRF. >> >> Cheers, >> Kiet >> >> On Fri, Sep 23, 2022 at 3:56 PM Nishant Sagar >> wrote: >> >>> Hey forks, >>> >>> I’m in little dilemma regarding Django forms. I'm working on a project >>> as a backend guy who doesn't know much about CSS and JavaScript so a >>> frontend guy delivered me a form template designed using CSS, however, >>> Django documentation suggests that it's good practice to use Django forms. >>> >>> So how feasible do you think it is for a frontend guy to learn Django >>> widgets from scratch to implement the same thing he can easily do from CSS >>> and JS. As a newbie backend guy, it's not easy for me either to learn >>> frontend tech to implement the same thing in so little time. >>> >>> So I tried implementing the form without using Django forms but I find >>> it hard to deal with files as there is no documentation I can look up to. >>> >>> So can we add these to the documentation or it is still advisable to use >>> Django forms? >>> >>> >>> Thanks and regards, >>> Nishant >>> >>> -- >>> 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/CANNtL-Kqud7V6sk_%3DYnagzATw8eJjO9pCeDx9Za80XywXBi2tQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/django-developers/CANNtL-Kqud7V6sk_%3DYnagzATw8eJjO9pCeDx9Za80XywXBi2tQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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/CAJ5pyZ%3DSVVNccLzS9iRDMWmZOtaVf90DroUWB_fDOjxWh3wTYQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAJ5pyZ%3DSVVNccLzS9iRDMWmZOtaVf90DroUWB_fDOjxWh3wTYQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM3gwruT%3DDw%3Dhb5yg%2Bd8i5_pFXaqKXUGU6Do7Qn%2B5JO8KA%40mail.gmail.com.
Re: Revisiting multiline template tags in Django Templates (again)
Big +1. IMO tags should work like HTML tags, which can be spread across multiple lines, as often done with multiple attributes. Also, Jinja does it. If you're going to write a DEP, I'd say don't make it too long. The feature is clear enough. The old PR <https://github.com/django/django/pull/2556> is also short, as it affects only the lexer. It should rebase fairly well as the lexer won't have changed much. I would plan to test it with as many templates as possible, to ensure that the tokenization is the same before/after. Happy to review... I'm planning on copying the lexer into django-upgrade so it can upgrade template files, so I would like to have some familiarity with it. On Wed, Sep 28, 2022 at 1:40 PM Alex Morega wrote: > Hi Thibaud, > > I don't have many contributions to Django, but FWIW, I'm happy to help > with development. > > On Wednesday, September 28, 2022 at 1:42:11 PM UTC+3 carlton...@gmail.com > wrote: > >> Hey Thibaud. >> >> Thanks for following up! Yes — happy to sheppard. >> >> (My other comment was to make sure the Rationale was sufficiently >> clear/compelling, but I know you're on that 😉) >> C. >> >> On Wed, 28 Sept 2022 at 12:24, Thibaud Colas wrote: >> >>> Just wanted to follow up that I got to discuss this in person with >>> Carlton Gibson at the DjangoCon Europe sprints in Porto, who provisionally >>> offered to act as a shepherd for this proposed DEP. This is on the >>> condition that I find an implementation team as well. >>> >>> On Saturday, 24 September 2022 at 08:37:52 UTC+1 Thibaud Colas wrote: >>> >>>> 👋 Hi django-developers, I would like to revisit a very old feature >>>> request: ticket #8652 Multiline tags and tag escape tags >>>> <https://code.djangoproject.com/ticket/8652>, proposed DEP Multiline >>>> Template Tags <https://github.com/django/deps/pull/3>, and maling list >>>> thread Revisiting multiline tags >>>> <https://groups.google.com/g/django-developers/c/wRKgnMIhl6g/m/hMRHPIz4CgAJ> >>>> . >>>> >>>> There have been a lot of cases made against and for multiline template >>>> tags across many threads. I’m raising this on the mailing list not >>>> necessarily to revisit those arguments but to ask: >>>> >>>>1. Is a DEP indeed the best way forward for this at this point in >>>>time? If so I will volunteer to author it (co-authors welcome!). >>>>2. The last DEP got blocked due to the lack of an implementation >>>>team and shepherd. If we made a new (proposed) DEP – is anyone here >>>>interested in helping in either positions? >>>> >>>> >>>> -- >>> 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-develop...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/ddc74d02-63df-479a-968c-2ee44b696bd2n%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/ddc74d02-63df-479a-968c-2ee44b696bd2n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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/af3c7629-4f7c-42b7-bb98-a0a67ef9af07n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/af3c7629-4f7c-42b7-bb98-a0a67ef9af07n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM1vF4rh7e2dTV3jp2tYH%3DVFz%3DuwSFqeSoHKjnPASMVdaQ%40mail.gmail.com.
Re: Optional URL parameters in django.urls.path
I'd also be -1. There are two good alternatives already, which are both
more flexible. No need to add a third way.
On Sun, Oct 2, 2022 at 8:35 AM Carlton Gibson
wrote:
> Hi.
>
> Re-reading again, I'm still not sure (personally) of the need/motivation
> given either of the "use two entries" or "use re_path()" options.
> Maybe it would be a nice-to-have but I'm not seeing the benefit as
> outweighing the complexity (remembering docs, and tests, and related
> functionality such as reverse() that would also need updating.)
>
> (IRL I've rarely needed this pattern. I've used both the options above
> without issue)
>
> So, I'd probably be -1 at this point.
>
> Kind regards
> Carlton
>
>
> On Sun, 2 Oct 2022 at 08:16, Meiyer wrote:
>
>> Is there any interest in implementing this feature? If yes, what would be
>> the syntax for the path components that would follow the optional parameter
>> (only if it is present)? I thought about something along the lines of
>> with the characters after the second colon having to
>> appear literally in the URL.
>> For example:
>> path(format_lazy('{org}/',
>> org=pgettext_lazy('URL', 'event/organizers/')), OrganizersView.as_vew())
>> would match both
>> /üritus/korraldajad/perekonnanimi/ and
>> /üritus/korraldajad/FI/perekonnanimi/ (in Estonian).
>> On Monday, September 19, 2022 at 4:07:26 PM UTC+2 matthew.pava wrote:
>>
>>> I wonder if maybe you should look at the APPEND_SLASH setting.
>>>
>>> https://docs.djangoproject.com/en/4.1/ref/settings/#append-slash
>>>
>>>
>>>
>>>
>>>
>>> *From:* django-d...@googlegroups.com *On
>>> Behalf Of *Meiyer
>>> *Sent:* Monday, September 19, 2022 8:59 AM
>>> *To:* Django developers (Contributions to Django itself) <
>>> django-d...@googlegroups.com>
>>> *Subject:* Re: Optional URL parameters in django.urls.path
>>>
>>>
>>>
>>> > One approach is to route two patterns (one with the parameter and one
>>> without) to the same URL. Some duplication but (perhaps) easier to read at
>>> a glance than either an optional `?` operator.
>>>
>>>
>>>
>>> I thought about that, but it won't work if I want both cases to be named
>>> similarly (via the `name` parameter). It also feels as duplicating the same
>>> line.
>>>
>>>
>>>
>>> > Given that — and the alternative re_path() approach being available —
>>> unless there was a particularly simple implementation on display I'd
>>> likely be sceptical about an addition here… 🤔
>>>
>>>
>>>
>>> I did a bit of digging in the Django code and in fact it might be quite
>>> easy (it is also possible I am missing the elephant). django.urls.resolvers
>>> defines the syntax for the path parameters on line 245 [1] and converts the
>>> matches to regular expressions on line 290 [2]. Looks like an addition of
>>> the '?' to the regex after the closing bracket would do it..?
>>>
>>>
>>>
>>>
>>>
>>> [1]
>>> https://github.com/django/django/blob/baf9604ed8fed3e6e7ddfaca2d83c377c81399ae/django/urls/resolvers.py#L245
>>>
>>> [2]
>>> https://github.com/django/django/blob/baf9604ed8fed3e6e7ddfaca2d83c377c81399ae/django/urls/resolvers.py#L290
>>>
>>> --
>>>
>>> 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-develop...@googlegroups.com.
>>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/9e0828d7-6434-4fd1-b605-8113342fcba9n%40googlegroups.com
>>> <https://us-east-2.protection.sophos.com?d=google.com&u=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzLzllMDgyOGQ3LTY0MzQtNGZkMS1iNjA1LTgxMTMzNDJmY2JhOW4lNDBnb29nbGVncm91cHMuY29tP3V0bV9tZWRpdW09ZW1haWwmdXRtX3NvdXJjZT1mb290ZXI=&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=TTVvYXJ0Y09ia2tXdUJNZlFiWnRBN1BhNExvNWh1d2tTT0poTDR6czhGaz0=&h=9fe189f5c8584ffea3e05d0fa18945a5>
>>> .
>>>
>> --
>> 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 receivi
Re: Why using django.contrib.sessions as the salt to encode session data? why not secret key?
Looking through blame, it looks like this hardcoded salt was added in 2010: https://github.com/django/django/commit/45c7f427ce830dd1b2f636fb9c244fda9201cadb#diff-3a6c11bbe36a0e6927f71ad8d669f0021897ba73768ee41073a318a12e11c3d1L85-L90 This actually changed from using the secret key as the salt, to the fixed string, whilst also changing the algorithm from MAC to HMAC. But I cannot see any discussion on why in the ticket: https://code.djangoproject.com/ticket/14445 . 🤷♂️ On Mon, Oct 3, 2022 at 8:43 AM Lokesh Sanapalli wrote: > Hi, > > I was going through the code and got a question. I saw that we are using > hard-coded string `django.contrib.sessions` as the key salt to encode > session data > <https://github.com/django/django/blob/main/django/contrib/sessions/backends/base.py#L64>. > Why not using the secret key? as the secret key is specific to environment > and project it serves as a good candidate. Is it because the session data > does not contain any sensitive info (it only contains user id and other > info) so that's why this decision is made? > > Thanks & Regards, > Lokesh Sanpalli > > -- > 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/6c6544b7-a190-4198-9108-6c66fac213ebn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/6c6544b7-a190-4198-9108-6c66fac213ebn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM1C6HxOVYrVL2XuBOhjWUb0EnThvzSAzocdKXrr%2BjkNEg%40mail.gmail.com.
Re: Why using django.contrib.sessions as the salt to encode session data? why not secret key?
Looking at the code, the hard-coded salt seems OK to me. The encoding is
done by SessionBase.encode()
<https://github.com/django/django/blob/c58a8acd413ccc992dd30afd98ed900897e1f719/django/contrib/sessions/backends/base.py#L92>,
which calls dumps() from django.core.signing
<https://github.com/django/django/blob/c58a8acd413ccc992dd30afd98ed900897e1f719/django/core/signing.py#L131>.
The docstring says:
*Return URL-safe, hmac signed base64 compressed JSON string. If key is
None, use settings.SECRET_KEY instead. The hmac algorithm is the default
Signer algorithm.If compress is True (not the default), check if
compressing using zlib can save some space. Prepend a '.' to signify
compression. This is included in the signature, to protect against zip
bombs.Salt can be used to namespace the hash, so that a signed string is
only valid for a given namespace. Leaving this at the default value or
re-using a salt value across different parts of your application without
good cause is a security risk.*
*The serializer is expected to return a bytestring.*
So, settings.SECRET_KEY is used to sign the session, and salt acts like a
namespace to distinguish sessions from other uses of the SECRET_KEY.
Trying it out in `./manage.py shell`:
>>> from django.contrib.sessions.backends.db import SessionStore
>>> from django.core.signing import b64_decode
>>> session = SessionStore().encode({"foo": "bar"})
>>> print(session)
eyJmb28iOiJiYXIifQ:1ogD1v:OIpRWKZdxbhox3d7XaS7A0bZouEXQV6jx03FlAaDGZo
>>> val, ts, sign = session.split(':')
SessionStore().encode({"foo": "bar"})
>>> b64_decode(val.encode())
b'{"foo":"bar"}'
>>> b64_decode(ts.encode())
b'\xd6\x88\x03\xd6'
>>> b64_decode(sign.encode())
b'8\x8aQX\xa6]\xc5\xb8h\xc7w{]\xa4\xbb\x03F\xd9\xa2\xe1\x17A^\xa3\xc7M\xc5\x94\x06\x83\x19\x9a'
>>> len(b64_decode(z.encode()))
32
The first section of the session value is the encoded value, base64
encoded, and potentially compressed.
The second section is the encoded timestamp, used to determine if it was
created too long ago on decode
The third section is the HMAC signature, base64 encoded.
- John
On Wed, Oct 5, 2022 at 4:45 PM 'Adam Johnson' via Django developers
(Contributions to Django itself) wrote:
> Looking through blame, it looks like this hardcoded salt was added in
> 2010:
> https://github.com/django/django/commit/45c7f427ce830dd1b2f636fb9c244fda9201cadb#diff-3a6c11bbe36a0e6927f71ad8d669f0021897ba73768ee41073a318a12e11c3d1L85-L90
>
> This actually changed from using the secret key as the salt, to the fixed
> string, whilst also changing the algorithm from MAC to HMAC. But I cannot
> see any discussion on why in the ticket:
> https://code.djangoproject.com/ticket/14445 .
>
> 🤷♂️
>
> On Mon, Oct 3, 2022 at 8:43 AM Lokesh Sanapalli
> wrote:
>
>> Hi,
>>
>> I was going through the code and got a question. I saw that we are using
>> hard-coded string `django.contrib.sessions` as the key salt to encode
>> session data
>> <https://github.com/django/django/blob/main/django/contrib/sessions/backends/base.py#L64>.
>> Why not using the secret key? as the secret key is specific to environment
>> and project it serves as a good candidate. Is it because the session data
>> does not contain any sensitive info (it only contains user id and other
>> info) so that's why this decision is made?
>>
>> Thanks & Regards,
>> Lokesh Sanpalli
>>
>> --
>> 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/6c6544b7-a190-4198-9108-6c66fac213ebn%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/6c6544b7-a190-4198-9108-6c66fac213ebn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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/CAMyDDM1C6HxOVYrVL2XuBOhjWUb0EnThvzSAzocdKXrr%2BjkNEg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM1C6HxOVYrVL2XuBOhjWUb0EnThv
Re: Model-level validation
ase inevitably involves supporting forms/payloads > that don't persist to a relational data store -- think of, for example, a > contact form that sends an email, or forms that store their results > client-side for things like language or theme preferences -- you inevitably > end up needing to do data conversion and validation *independently of the > ORM*. > > And at that point, you have to start asking tough questions about whether > it's worth having *two* conversion and validation layers, just because > "every other ORM has this, so we have to put one in the ORM". > > Which basically is where Django is. Yes, there are utilities to do your > data conversion and validation in the ORM layer if you want to. But Django > is, first and foremost, a web framework, which needs to support the web use > case I've described above, and so its primary conversion/validation layer > can never be the ORM. > > Personally, I wish model-level validation had never been added even as an > option, because in a web framework like Django it's conceptually the wrong > place to put the validation logic. Though that battle was lost many years > ago, I'd be *strongly* against trying to expand it or start forcing the ORM > to default to doing validation work that, in Django, properly belongs to > the forms layer (or to serializers if you use DRF). > > So: Django ships with ModelForm, which does the hard work of auto-deriving > as much validation logic as possible from your model definition so you > don't have to repeat it. DRF ships with ModelSerializer, which does the > same thing for its validation/conversion layer. I would strongly urge > people to use them. Trying to force all that validation back into the model > layer misses the bigger picture of what Django is and how it works. > -- 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/65af21e8-a420-4e86-98da-c39e59258002n%40googlegroups.com.
Re: ArrayField: Bug on exact_nested_null
Yes please create a ticket. If you’re feeling brave, try to adapt your test
into Django’s test suite (here:
https://github.com/django/django/blob/84206607d6bfd61e7f7a88b51163ffd4153e3b5a/tests/postgres_tests/test_array.py#L212
)!
On Sun, Oct 9, 2022 at 11:49 AM Ion Alberdi
wrote:
> Hello to all,
>
> a unit test added at
> https://github.com/pricemoov/django/pull/2
> shows that the exact filter on a full "NULL nested array" currently fails.
> (the commit messages shows how to reproduce the error).
>
> More precisely, the error is
> "django.db.utils.DataError: invalid input syntax for type integer:
> "{NULL,NULL}"
>
> LINE 1: ...ullableintegerarraymodel"."field_nested" =
> (ARRAY['{NULL,NUL..."
>
> and seems to be due to the query being generated as
> "...ARRAY['{NULL,NULL}']..."
> instead of "...ARRAY[ARRAY[NULL,NULL]]..."
>
> I wonder whether this is due to django or psycopg2. Indeed, the bug is not
> reproduced
> if at least one of the element in the nested array is not null.
>
> Is the bug worth creating a ticket?
>
> Best regards,
>
> --
> 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/bad3435e-1299-4b1d-b701-7881e111ec90n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/bad3435e-1299-4b1d-b701-7881e111ec90n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMyDDM1Rs%3DxZjChzqU3qj6YttB3atLX7bhGuURd0-3v_OitK0g%40mail.gmail.com.
Re: ArrayField: Bug on exact_nested_null
Ah sorry didn't realize.
I would just link to the test from your ticket for now, the fellows are
probably in a better position to determine how to treat this bug.
On Mon, Oct 10, 2022 at 8:47 AM Ion Alberdi
wrote:
> Great, thanks Adam! FYI the test is already on django's Test suite
> (https://github.com/pricemoov/django/pull/2/files)
> Would you like me to open a PR in Django or should I wait for the fix of
> the test being developed first?
>
>
> Le lun. 10 oct. 2022 à 09:39, 'Adam Johnson' via Django developers
> (Contributions to Django itself) a
> écrit :
>
>> Yes please create a ticket. If you’re feeling brave, try to adapt your
>> test into Django’s test suite (here:
>> https://github.com/django/django/blob/84206607d6bfd61e7f7a88b51163ffd4153e3b5a/tests/postgres_tests/test_array.py#L212
>> )!
>>
>> On Sun, Oct 9, 2022 at 11:49 AM Ion Alberdi
>> wrote:
>>
>>> Hello to all,
>>>
>>> a unit test added at
>>> https://github.com/pricemoov/django/pull/2
>>> shows that the exact filter on a full "NULL nested array" currently
>>> fails.
>>> (the commit messages shows how to reproduce the error).
>>>
>>> More precisely, the error is
>>> "django.db.utils.DataError: invalid input syntax for type integer:
>>> "{NULL,NULL}"
>>>
>>> LINE 1: ...ullableintegerarraymodel"."field_nested" =
>>> (ARRAY['{NULL,NUL..."
>>>
>>> and seems to be due to the query being generated as
>>> "...ARRAY['{NULL,NULL}']..."
>>> instead of "...ARRAY[ARRAY[NULL,NULL]]..."
>>>
>>> I wonder whether this is due to django or psycopg2. Indeed, the bug is
>>> not reproduced
>>> if at least one of the element in the nested array is not null.
>>>
>>> Is the bug worth creating a ticket?
>>>
>>> Best regards,
>>>
>>> --
>>> 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/bad3435e-1299-4b1d-b701-7881e111ec90n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/bad3435e-1299-4b1d-b701-7881e111ec90n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/4OvbN0EUUsM/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/CAMyDDM1Rs%3DxZjChzqU3qj6YttB3atLX7bhGuURd0-3v_OitK0g%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAMyDDM1Rs%3DxZjChzqU3qj6YttB3atLX7bhGuURd0-3v_OitK0g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> [image: img] <https://signitic.app/linkc/L3B5SXlwV0U-L3A4PQ>
>
>
> *Ion Alberdi*
>
>
> [image: img] <https://signitic.app/linkc/L3B5SXlwV0U-L1pzPQ> [image: img]
> <https://signitic.app/linkc/L3B5SXlwV0U-L3A4PQ> [image: img]
> <https://signitic.app/linkc/L3B5SXlwV0U-L1pRPQ> [image: img]
> <https://signitic.app/linkc/L3B5SXlwV0U-L1pnPQ> [image: img]
> <https://signitic.app/linkc/L3B5SXlwV0U-L1prPQ>
>
> --
> 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/CANbgw4B81hwFvRhCVQpm%3DPg%3D_ZJikTVKKhAaXa%2B7rPpw8%3DoVEw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CANbgw4B81hwFvRhCVQpm%3DPg%3D_ZJikTVKKhAaXa%2B7rPpw8%3DoVEw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMyDDM19RVNqA0OiDqpwdNq0SD_uPCGr8Gz4XiWQFEqd4EZ90A%40mail.gmail.com.
Re: Why using django.contrib.sessions as the salt to encode session data? why not secret key?
Thank you for diving into this John! All seems sensible then.
On Wed, Oct 5, 2022 at 11:53 PM 'John Whitlock' via Django developers
(Contributions to Django itself) wrote:
> Looking at the code, the hard-coded salt seems OK to me. The encoding is
> done by SessionBase.encode()
> <https://github.com/django/django/blob/c58a8acd413ccc992dd30afd98ed900897e1f719/django/contrib/sessions/backends/base.py#L92>,
> which calls dumps() from django.core.signing
> <https://github.com/django/django/blob/c58a8acd413ccc992dd30afd98ed900897e1f719/django/core/signing.py#L131>.
> The docstring says:
>
>
>
>
>
>
> *Return URL-safe, hmac signed base64 compressed JSON string. If key is
> None, use settings.SECRET_KEY instead. The hmac algorithm is the default
> Signer algorithm.If compress is True (not the default), check if
> compressing using zlib can save some space. Prepend a '.' to signify
> compression. This is included in the signature, to protect against zip
> bombs.Salt can be used to namespace the hash, so that a signed string is
> only valid for a given namespace. Leaving this at the default value or
> re-using a salt value across different parts of your application without
> good cause is a security risk.*
>
> *The serializer is expected to return a bytestring.*
>
> So, settings.SECRET_KEY is used to sign the session, and salt acts like a
> namespace to distinguish sessions from other uses of the SECRET_KEY.
>
> Trying it out in `./manage.py shell`:
>
> >>> from django.contrib.sessions.backends.db import SessionStore
> >>> from django.core.signing import b64_decode
> >>> session = SessionStore().encode({"foo": "bar"})
> >>> print(session)
> eyJmb28iOiJiYXIifQ:1ogD1v:OIpRWKZdxbhox3d7XaS7A0bZouEXQV6jx03FlAaDGZo
> >>> val, ts, sign = session.split(':')
> SessionStore().encode({"foo": "bar"})
> >>> b64_decode(val.encode())
> b'{"foo":"bar"}'
> >>> b64_decode(ts.encode())
> b'\xd6\x88\x03\xd6'
> >>> b64_decode(sign.encode())
>
> b'8\x8aQX\xa6]\xc5\xb8h\xc7w{]\xa4\xbb\x03F\xd9\xa2\xe1\x17A^\xa3\xc7M\xc5\x94\x06\x83\x19\x9a'
> >>> len(b64_decode(z.encode()))
> 32
>
> The first section of the session value is the encoded value, base64
> encoded, and potentially compressed.
> The second section is the encoded timestamp, used to determine if it was
> created too long ago on decode
> The third section is the HMAC signature, base64 encoded.
>
> - John
>
> On Wed, Oct 5, 2022 at 4:45 PM 'Adam Johnson' via Django developers
> (Contributions to Django itself)
> wrote:
>
>> Looking through blame, it looks like this hardcoded salt was added in
>> 2010:
>> https://github.com/django/django/commit/45c7f427ce830dd1b2f636fb9c244fda9201cadb#diff-3a6c11bbe36a0e6927f71ad8d669f0021897ba73768ee41073a318a12e11c3d1L85-L90
>>
>> This actually changed from using the secret key as the salt, to the fixed
>> string, whilst also changing the algorithm from MAC to HMAC. But I cannot
>> see any discussion on why in the ticket:
>> https://code.djangoproject.com/ticket/14445 .
>>
>> 🤷♂️
>>
>> On Mon, Oct 3, 2022 at 8:43 AM Lokesh Sanapalli
>> wrote:
>>
>>> Hi,
>>>
>>> I was going through the code and got a question. I saw that we are
>>> using hard-coded string `django.contrib.sessions` as the key salt to encode
>>> session data
>>> <https://github.com/django/django/blob/main/django/contrib/sessions/backends/base.py#L64>.
>>> Why not using the secret key? as the secret key is specific to environment
>>> and project it serves as a good candidate. Is it because the session data
>>> does not contain any sensitive info (it only contains user id and other
>>> info) so that's why this decision is made?
>>>
>>> Thanks & Regards,
>>> Lokesh Sanpalli
>>>
>>> --
>>> 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/6c6544b7-a190-4198-9108-6c66fac213ebn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/6c6544b7-a190-4198-9108-6c66fac213ebn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>&g
Re: Proposal: Clarify the ENV var that controls the autoreloader so AppConfig's ready() can be have a guard.
Steffan Your question suffers from the ”X/Y problem”. You’re asking whether to change Django to make Y easy, without explaining the X you’re trying to achieve. *Why* do you want to know if you're in the runserver main process? Also, it may work to check the running command from sys.argv ( https://adamj.eu/tech/2020/05/14/how-to-check-the-running-django-command/ ). If it’s runserver, and the env var isn’t set, then you can tell. Thanks, Adam On Sat, Oct 15, 2022 at 4:09 AM Steffan Pease wrote: > AppConfig's ready() function gets called multiple times on manage.py > runserver and some tests because multiple copies of django are started, > even though none are 'active.' > > To use runserver as an example, it launches the original process's > runserver checks if DJANGO_AUTORELOAD_ENV == "true", and if it doesn't > exist, it spawns child processes with that ENV var set. > > At the same codepoint in the child, since DJANGO_AUTORELOAD_ENV is set, it > issues start_django (with the reloader argument set). > > In other words, you can tell when you're in a running 'server' and not a > doomed launcher by checking if DJANGO_AUTORELOAD_ENV == "true", but only > when using runserver. If it's unset, we could either be a non-runserver > django, or a doomed launcher. > > If DJANGO_AUTORELOAD_ENV was set to "false" in run_with_reloader when we > spawn the child process, then in AppConfig we can guard the ready() call, > since a value of "true" or None means we're an active running server. We > can use > > if os.environ.get(DJANGO_AUTORELOAD_ENV) != "false": > > and only trigger ready() once, which I think would be the 'expected' > behavior the average user would expect. > > Alternately, the same thing could be done, but instead of guarding the > ready() call, a function (is_autoloader, maybe?) could be exposed to the > end user, to let them make the decision themselves. > > To my knowledge, as things are now, there's no other way to determine > this. The best you can do is check for a flag on AppConfig that you setattr > if it wasn't, but there's no way to directly tell which process you're in. > > Thoughts? > > -- > 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/36d6ba80-34a5-4aed-aca3-4a30234c3f92n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/36d6ba80-34a5-4aed-aca3-4a30234c3f92n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM0EXooGULj_kza0iRjkpwqx%2BoG_i26NGBMxsdAoaj_Fjg%40mail.gmail.com.
Re: Proposal: Add An in-memory data storage backend in Django
+1 from me. Using in-memory storage is great for tests. On Thu, Oct 20, 2022 at 6:30 PM Paolo Melchiorre (paulox) < pa...@melchiorre.org> wrote: > Hi all, > > there is a package that provide in-memory data storage backend, but it's > now abandoned. > > Having support for in-memory data storage could be very useful for Django > itself and furthermore it would involve adding a small code with tests that > do not justify the creation of a fork of that old package. > > We are talking about this during the sprints at DjangoCon US 2023 in San > Diego with Josh Thomas and Mariusz Felisiak proposed to us to ask here on > this list. > > What do you think about adding an in-memory data storage backend directly > in the Django core? > > Ciao, > Paolo > > -- > 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/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM3urOZ5rxg85B7Y4FzqZFsjmrMz2_44hPHfZz%2Bi2-Zy9w%40mail.gmail.com.
Re: Proposal: Add An in-memory data storage backend in Django
Hi, I also may be missing some context, but is this the mentioned package? https://github.com/waveaccounting/dj-inmemorystorage I have not used it, but it looks like a useful tool to have! Tobias On Thu, Oct 20, 2022 at 7:50 PM David Sanders wrote: > Hi, > > I may be missing some context here but is this something distinctly > different from setting SQLite to use in-memory storage [1]? 🤔 > > [1] https://www.sqlite.org/inmemorydb.html > > David > > On Fri, 21 Oct 2022, 04:30 Paolo Melchiorre (paulox), < > pa...@melchiorre.org> wrote: > >> Hi all, >> >> there is a package that provide in-memory data storage backend, but it's >> now abandoned. >> >> Having support for in-memory data storage could be very useful for Django >> itself and furthermore it would involve adding a small code with tests that >> do not justify the creation of a fork of that old package. >> >> We are talking about this during the sprints at DjangoCon US 2023 in San >> Diego with Josh Thomas and Mariusz Felisiak proposed to us to ask here on >> this list. >> >> What do you think about adding an in-memory data storage backend directly >> in the Django core? >> >> Ciao, >> Paolo >> >> -- >> 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/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CADyZw-64SU%2BdwjKDGmzCZpz06VZ-QUxjb3%2B9RGFp8vqbJSd58Q%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CADyZw-64SU%2BdwjKDGmzCZpz06VZ-QUxjb3%2B9RGFp8vqbJSd58Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMGFDKRiEsi7BqaNUJGFWNYqpfP3Cq8TVx3fQYuuYp9ii-injw%40mail.gmail.com.
Re: Intention behind `adelete` being a queryset method, and not available on a model instance?
This is intentional, as it stands. Django 4.1 only added async QuerySet methods, not async Model methods. Async model methods like adelete(), and perhaps asave(), would be the next logical step. On Fri, Oct 21, 2022 at 1:47 PM Jason Johns wrote: > I came across a reddit post yesterday > <https://www.reddit.com/r/django/comments/y7w5dm/django_async_delete_from_db/>about > `adelete` raising an attribute error > > r = await mymodel.objects.aget(some_name=myname) > await r.adelete() > > would throw an `AttributeError`, > > whereas r = await mymodel.objects.filter(some_name=myname).adelete() works > as expected. > > I was a little curious about this, and adelete > <https://docs.djangoproject.com/en/4.1/ref/models/querysets/#django.db.models.query.QuerySet.adelete> > is > explicitly called out in the queryset docs within the `delete` section. > but the models doc page > <https://docs.djangoproject.com/en/4.1/ref/models/instances/#deleting-objects>only > contains items about `delete`. Is this intentional or not, and if it is > intentional, perhaps a specific call-out in both queryset and model delete > sections would help with clarification. > > -- > 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/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM3L6gz0i9dp7S5xsmE8%2B7GCeY1L5A0h%2BQKxGv7zs6pu9w%40mail.gmail.com.
Re: Intention behind `adelete` being a queryset method, and not available on a model instance?
If you have a suggestion, sure. But from my perspective the docs are clear. There's an adelete() method doc'd for QuerySet, and not for Model, and the release note <https://docs.djangoproject.com/en/4.1/releases/4.1/#asynchronous-orm-interface> says “QuerySet now provides an asynchronous interface...”. On Fri, Oct 21, 2022 at 3:51 PM Jason Johns wrote: > gotcha, then perhaps a documentation tweak would be in order, on both > queryset and model pages? because as is, its unclear this is expected. > > On Friday, October 21, 2022 at 9:57:33 AM UTC-4 Adam Johnson wrote: > >> This is intentional, as it stands. Django 4.1 only added async QuerySet >> methods, not async Model methods. Async model methods like adelete(), and >> perhaps asave(), would be the next logical step. >> >> On Fri, Oct 21, 2022 at 1:47 PM Jason Johns wrote: >> >>> I came across a reddit post yesterday >>> <https://www.reddit.com/r/django/comments/y7w5dm/django_async_delete_from_db/>about >>> `adelete` raising an attribute error >>> >>> r = await mymodel.objects.aget(some_name=myname) >>> await r.adelete() >>> >>> would throw an `AttributeError`, >>> >>> whereas r = await mymodel.objects.filter(some_name=myname).adelete() >>> works as expected. >>> >>> I was a little curious about this, and adelete >>> <https://docs.djangoproject.com/en/4.1/ref/models/querysets/#django.db.models.query.QuerySet.adelete> >>> is >>> explicitly called out in the queryset docs within the `delete` section. >>> but the models doc page >>> <https://docs.djangoproject.com/en/4.1/ref/models/instances/#deleting-objects>only >>> contains items about `delete`. Is this intentional or not, and if it is >>> intentional, perhaps a specific call-out in both queryset and model delete >>> sections would help with clarification. >>> >>> -- >>> 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-develop...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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/cbb9dbba-be64-4c97-abfe-0b42ed42ddb3n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/cbb9dbba-be64-4c97-abfe-0b42ed42ddb3n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM2VVLGVW01ZcOHPeKk_KafOZ2uEXwjAgqSdjGQb0yBBcg%40mail.gmail.com.
Re: Intention behind `adelete` being a queryset method, and not available on a model instance?
I opened a ticket to add async methods to Model: https://code.djangoproject.com/ticket/34112 This would be released in Django 4.2, at minimum. Using async to perform model updates is not likely to be performant, since the queries end up being processed synchronously on a thread anyway. This is because the database libraries Django supports don't have async interfaces. On Fri, Oct 21, 2022 at 4:49 PM Adam Johnson wrote: > If you have a suggestion, sure. But from my perspective the docs are > clear. There's an adelete() method doc'd for QuerySet, and not for Model, > and the release note > <https://docs.djangoproject.com/en/4.1/releases/4.1/#asynchronous-orm-interface> > says “QuerySet now provides an asynchronous interface...”. > > On Fri, Oct 21, 2022 at 3:51 PM Jason Johns wrote: > >> gotcha, then perhaps a documentation tweak would be in order, on both >> queryset and model pages? because as is, its unclear this is expected. >> >> On Friday, October 21, 2022 at 9:57:33 AM UTC-4 Adam Johnson wrote: >> >>> This is intentional, as it stands. Django 4.1 only added async QuerySet >>> methods, not async Model methods. Async model methods like adelete(), and >>> perhaps asave(), would be the next logical step. >>> >>> On Fri, Oct 21, 2022 at 1:47 PM Jason Johns wrote: >>> >>>> I came across a reddit post yesterday >>>> <https://www.reddit.com/r/django/comments/y7w5dm/django_async_delete_from_db/>about >>>> `adelete` raising an attribute error >>>> >>>> r = await mymodel.objects.aget(some_name=myname) >>>> await r.adelete() >>>> >>>> would throw an `AttributeError`, >>>> >>>> whereas r = await mymodel.objects.filter(some_name=myname).adelete() >>>> works as expected. >>>> >>>> I was a little curious about this, and adelete >>>> <https://docs.djangoproject.com/en/4.1/ref/models/querysets/#django.db.models.query.QuerySet.adelete> >>>> is >>>> explicitly called out in the queryset docs within the `delete` section. >>>> but the models doc page >>>> <https://docs.djangoproject.com/en/4.1/ref/models/instances/#deleting-objects>only >>>> contains items about `delete`. Is this intentional or not, and if it is >>>> intentional, perhaps a specific call-out in both queryset and model delete >>>> sections would help with clarification. >>>> >>>> -- >>>> 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-develop...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com >>>> <https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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/cbb9dbba-be64-4c97-abfe-0b42ed42ddb3n%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/cbb9dbba-be64-4c97-abfe-0b42ed42ddb3n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAMyDDM3H_JhAYwDhrFs5kpv8C8iq1eGBUbQ1hxOenpZ8rb%2BsqA%40mail.gmail.com.
Re: Proposal for Django Core Sprints
Hybrid sound the best way, with remote first as otherwise you are excluding people who would need air travel that's not covered by someone else and can be very expensive how and are thus increasing a carbon footprint for something that really doesn't need it On Thursday, 27 October 2022 at 01:49:53 UTC+1 pa...@melchiorre.org wrote: > Hi Andrew, > > Thanks also to you for your very detailed answer. > > On Thu, Oct 27, 2022 at 1:54 AM Andrew Godwin wrote: > > > ... trying to organise an additional in-person event that a large number > of contributors are expected to go to is difficult > > I am aware that this proposal of mine to the DSF board is not easy, > but I think it could have positive effects as I have seen it happen in > the past and as it still happens today in other communities. > > > ... who do you invite (and presumably help pay for)? We no longer have a > core team ... > > I understand that the term "core" has triggered some old discussion > that I am not aware of, but in my proposal it refers to the scope of > the code to work on. > > > ...it's a hard metric to gauge. > > This is something that we could decide together. > > > ... while I do believe it should be a hybrid event, I also think it > should not be a remote-only event. > > On this point you seem to agree with my proposal > > > The final question I would raise is that of location ... > > I tried to give general indications on the location in my proposal so > that I could then decide a place based on the actual participants of a > given sprint, without imposing a predefined location or nation. > > > I didn't even discuss how we might fund this... > > Surely here too I left generic indications, because it seemed to me > more than once to understand that the DSF board would not have too > many problems in receiving new funds as long as they were destined for > a specific objective. > > For example, imagine a sprint working on only one of the proposals you > listed in your last talk, it could be a point that many may have an > interest in financing directly. > > Grazie, > Paolo > > > On Wed, Oct 26, 2022, at 4:01 PM, Paolo Melchiorre wrote: > > Hi everyone, > > Following Andrew Godwin's example, I too share with you a proposal > > that I made during DjangoCon US 2022 and that I have already shared > > with some of you. > > Inspired by an article by Will Vincent, I wrote my proposal for Django > > Core Sprints, and its genesis, in an article and would also like to > > have the opinions of the Django community members interested in the > > idea: > > > https://www.paulox.net/2022/10/26/about-my-proposal-for-the-django-core-sprints/ > > -- > Paolo Melchiorre > > https://www.paulox.net > -- 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/994f5282-05b0-465b-8d13-851109f985c2n%40googlegroups.com.
Re: Warning in documentation about filtering queryset in ClassBasedViews
I'm inclined to agree with David here. This is a “understanding Python” thing. We can’t feasibly add documentation warnings everywhere such a mistake could be made. On Sat, Oct 29, 2022 at 8:00 PM David Sanders wrote: > Hi Daniel, > > I don't think a warning is necessary here as it's fairly standard Python. > > To explain: the timezone.now() is evaluated at module level – ie only once > when the Python module is imported – which explains the behaviour that > you're experiencing. > > If you like you can submit a documentation PR with some suggestions but > others may also doubt the value of adding a warning given that the very > next section explains how to do dynamic filtering. Personally I think by > the time you get to advanced Django such as this, Python experience is > assumed :) > > Regards, > David > > On Sun, 30 Oct 2022 at 00:02, Daniel Gayoso González < > danigayo...@gmail.com> wrote: > >> Hello, >> >> Following the example in >> https://docs.djangoproject.com/en/4.1/topics/class-based-views/generic-display/#viewing-subsets-of-objects >> I tried the following >> >> class BookListView(ListView): >> model = Book >> queryset = Book.objects.filter(publication_date__lte=timezone.now()) >> >> I found that this code snippet to retrieve only books that has the >> publication date before today (assuming that could be books with >> publication date in the future) not work as I would expected. >> >> After some digging, I found that timezone.now() it's cached when server >> starts up (in a production environment), so this query filter by the date >> the server was started. So the solution is to use a dynamic filtering. >> >> Could be a good idea to include some warning about this in the >> documentation? >> >> Thanks, >> Daniel >> >> -- >> 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/CAHLCT5d3Dz3KTfpxhLQAUZjruhRLgb_XKbUKdv7VgHW_-VVfCg%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAHLCT5d3Dz3KTfpxhLQAUZjruhRLgb_XKbUKdv7VgHW_-VVfCg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CADyZw-59A5U0pLOuZ%2BxdfHp%3Dq%3Ddwgw%2BG_GFaRYQAxfdytX6%2B5Q%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CADyZw-59A5U0pLOuZ%2BxdfHp%3Dq%3Ddwgw%2BG_GFaRYQAxfdytX6%2B5Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM2%2BhHoz%3DeXHQc2nHQnoLz88t5L2N%3DooUgr75aPHQ4_FUg%40mail.gmail.com.
Re: #21978 include production-ready web server
gt;> Tim Allen also recently raised improving the Django project template, >>>>>> which I think is related here. (That's on my list too: async this QTR, >>>>>> then >>>>>> hoping to take on Adam's proposal to modernise the Request object for the >>>>>> end of year, then 🤞 swinging back here for "OK, what does it look like, >>>>>> what can we do?" after that: there's a bunch of related tickets around >>>>>> #21978 that it would be very sweet if we could clear up...) >>>>>> >>>>>> I think all these thoughts are really pursuable outside of core in >>>>>> the very short run, even if the goal is to merge them — it's much easier >>>>>> to >>>>>> experiment that way, and then say, "This worked". >>>>>> >>>>>> Anyhow, other than a "I've been thinking along these lines", and a >>>>>> generally positive emote, I don't have too much more concrete at this >>>>>> stage. >>>>>> 👍 >>>>>> C. >>>>>> >>>>>> On Tue, 23 Aug 2022 at 19:00, Peter Baumgartner < >>>>>> pe...@lincolnloop.com> wrote: >>>>>> >>>>>>> Thanks for the additional background Carlton! I like the idea of >>>>>>> having some sort of protocol that folks can follow to make >>>>>>> ready-to-use Django server packages (django-webserver [1] is in the >>>>>>> same vein), but I'd strive for more. pip install + INSTALLED_APPS is >>>>>>> great, but getting to production with that approach can feel like >>>>>>> death by a thousand paper cuts. Do that with gunicorn, whitenoise, >>>>>>> dj-database-url, etc. and it ends up being a laundry list of things >>>>>>> that, in my experience, people rarely get right on the first try and >>>>>>> just result in frustration. >>>>>>> >>>>>>> It seems like part of the challenge here is reaching parity with the >>>>>>> current runserver command, but is that necessary? Running `runserver >>>>>>> --dev` locally and getting dev features like autoreloading and then >>>>>>> having `runserver` use a different server for a deployed app doesn't >>>>>>> seem unreasonable. >>>>>>> >>>>>>> [1] https://github.com/lincolnloop/django-webserver >>>>>>> >>>>>>> On Tue, Aug 23, 2022 at 10:14 AM Carlton Gibson >>>>>>> wrote: >>>>>>> > >>>>>>> > Hey Pete. >>>>>>> > >>>>>>> > Yes... this is a good one. >>>>>>> > >>>>>>> > It's difficult to see how we can even have an ASGI runserver in >>>>>>> core, simply because there's no SimpleServer equivalent as there is for >>>>>>> WSGI, and it's not clear one is on the card. (HTTP is getting **more** >>>>>>> complex, and I can't see Python bringing such into the standard >>>>>>> library.) >>>>>>> > So we have to use a third-party dependency for that. >>>>>>> > >>>>>>> > For the Channels v4 update (in progress now) I'm moving the >>>>>>> runserver command to the Daphne package. This was because folks wanted >>>>>>> to >>>>>>> use Channels without the Daphne/Twisted dependency. >>>>>>> > >>>>>>> > See: https://github.com/django/daphne/pull/429 >>>>>>> > >>>>>>> > tl;dr — it came out pretty clean TBH. You pip install daphne, then >>>>>>> add "daphne" at the top of INSTALLED_APPS. (There's a system check to >>>>>>> make >>>>>>> sure you're not fighting staticfiles.) >>>>>>> > >>>>>>> > On the back of that I don't see why servers (any servers) can't >>>>>>> provide a runserver command (or a django-* mini-package to go with it) >>>>>>> and >>>>>>> offer what they offer in development as well as production. (Obviously >>>>>>> that >>>>>>&
Re: How reload django settings on run RestService
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.
For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you
find people who are willing to support you, and to ask your question in a
way that makes it easy for them to answer.
Thanks for your understanding and all the best,
Adam
On Mon, Oct 31, 2022 at 1:16 PM Lakhvinder Singh
wrote:
> i try it
>
> https://github.com/sunscrapers/djoser/blob/master/djoser/conf.py
>
> user->settings.py use for settings load on global
>
> from copy import deepcopy
>
> from django.core.exceptions import ImproperlyConfigured
> from django.conf import settings
>
>
> default_settings = {
> 'SEND_ACTIVATION_EMAIL': False,
> 'SEND_CONFIRMATION_EMAIL': False,
> 'SET_PASSWORD_RETYPE': False,
> 'SET_USERNAME_RETYPE': False,
> 'PASSWORD_RESET_CONFIRM_RETYPE': False,
> 'PASSWORD_RESET_SHOW_EMAIL_NOT_FOUND': False,
> 'ROOT_VIEW_URLS_MAPPING': {},
> 'PASSWORD_VALIDATORS': [],
> 'SERIALIZERS': {
> 'activation': 'user.serializers.ActivationSerializer',
> 'login': 'user.serializers.LoginSerializer',
>
> },
> 'LOGOUT_ON_PASSWORD_CHANGE': False,
> }
>
>
> def get(key):
> user_settings = merge_settings_dicts(
> deepcopy(default_settings), getattr(settings, 'USER_APP', {}))
> try:
> return user_settings[key]
> except KeyError:
> raise ImproperlyConfigured('Missing settings:
> USER_APP[\'{}\']'.format(key))
>
>
> def merge_settings_dicts(a, b, path=None, overwrite_conflicts=True):
> """merges b into a, modify a in place
>
> Found at http://stackoverflow.com/a/7205107/1472229
> """
> if path is None:
> path = []
> for key in b:
> if key in a:
> if isinstance(a[key], dict) and isinstance(b[key], dict):
> merge_settings_dicts(a[key], b[key], path + [str(key)],
> overwrite_conflicts=overwrite_conflicts)
> elif a[key] == b[key]:
> pass # same leaf value
> else:
> if overwrite_conflicts:
> a[key] = b[key]
> else:
> conflict_path = '.'.join(path + [str(key)])
> raise Exception('Conflict at %s' % conflict_path)
> else:
> a[key] = b[key]
> # Don't let this fool you that a is not modified in place
> return a
>
>
>
> --
> 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/2370e781-b2a6-404e-b943-b96892b49137n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/2370e781-b2a6-404e-b943-b96892b49137n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMyDDM37vqxMJyx4VAch_QV3icNmKBc692XpwnXHQYNY9Mn5bw%40mail.gmail.com.
Re: #21978 include production-ready web server
config.get is how python-decouple works which is what I use for config and
deployment settings.
On Tuesday, 1 November 2022 at 09:34:15 UTC f.apo...@gmail.com wrote:
> Right, that would work. I am wondering though if we want to go all in on a
> typed config object like that or in a first step only have a simple API
> like `config.get('DEBUG', cast=bool)`.
>
> On Tuesday, November 1, 2022 at 3:35:46 AM UTC+1 pe...@lincolnloop.com
> wrote:
>
>> On Mon, Oct 31, 2022 at 11:52 AM Florian Apolloner
>> wrote:
>>
>>> On Monday, October 31, 2022 at 5:27:02 PM UTC+1 pe...@lincolnloop.com
>>> wrote:
>>>
>>>> In my ideal scenario, the default is a hard-coded settings file for the
>>>> project (deprecating DJANGO_SETTINGS_MODULE env var) and we have
>>>> CONFIG_LOADERS defined in the settings that could do env, toml, etc.
>>>> Perhaps things like django.setup,
>>>>
>>> django.core.wsgi.get_wsgi_application, and
>>>> django.core.management.execute_from_command_line could accept the settings
>>>> module as an argument? django-admin could accept a --settings flag?
>>>>
>>>
>>> I doubt that will ever fly. There is no project so to say in Django.
>>> Currently literally everything depends on knowing a
>>> `DJANGO_SETTINGS_MODULE` from which everything else can follow (even the
>>> wsgi app…). So without a settings file how would you know that hard-coded
>>> path for it? Django has no concept of a project that you could import. You
>>> also cannot easily put `CONFIG_LOADERS` in a settings file like we
>>> currently have because then how are you going to evaluate that while also
>>> executing all the other module level stuff. And django-admin command all
>>> already support a `--settings` flag (as alternative to
>>> DJANGO_SETTINGS_MODULE ;))
>>>
>>> Either way I doubt we will deprecating DJANGO_SETTINGS_MODULE any time
>>> soon. And I don't see it such of a problem with being there. Projects can
>>> set it (and startproject already does this) to a fixed value in manage.py &
>>> wsgi.py. For a project that installs a custom entrypoint script, you can
>>> also preset it to whatever you like.
>>>
>>> Please note that we are trying to load stuff from files & env vars in
>>> the first step, not throw out settings.py at the same time…
>>>
>>
>> I figured it wouldn't fly :)
>>
>> I misunderstood your chicken-egg question above. What I've been doing is
>> defining a "Config" class and instantiating it in the settings file.
>> Instantiation of the class (or calling an explicit method on it) would do
>> the env/file loading and the instance becomes your `env` object. Rather
>> than having a CONFIG_LOADERS setting, you could define them on the Config
>> class or when you instantiate it. This is pretty similar to how goodconf
>> works today. https://github.com/lincolnloop/goodconf#quick-start
>>
>>
>>>
>>> Cheers,
>>> Florian
>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/b0cc8e42-0781-4a69-b8a1-12cc6929c2f7n%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/django-developers/b0cc8e42-0781-4a69-b8a1-12cc6929c2f7n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
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/5ebb70e7-9118-4989-9a32-7b1faa9f032dn%40googlegroups.com.
Re: Proposal: filter by multiple values, case-insensitive
This can currently be achieved with:
qs.annotate(lowername=Lower("name")).filter(lowername__in=['text'])
You’re free to add “iin” to your projects, but I'm not sure it's valuable
enough to add to Django.
Some years ago, there was an idea to allow python expressions to generate
ORM filters, that would allow your lookup to done without any extensions:
https://github.com/django/django/pull/12041 .
On Sat, Oct 29, 2022 at 6:22 AM Jeremy Nauta wrote:
> Hi all, I'd like to propose a new django filter: *__iin*. As the name
> implies, this filter finds results that match one of the given values,
> ignoring case. In other words, this is a hybrid of *__in *and *__iexact*.
>
> It surprises me that there are filters for*
> qs.filter(field__iexact='text')*, *qs.filter(field__icontains='text')*,
> and *qs.filter(field__in=[**'text']**)*, yet there is no
> *qs.filter(field__iin=[**'text']**)* filter.
>
> I've made a POC for this field in postgres and it seems quite
> straightforward. I'd be happy to try porting into the Django codebase, but
> first I wanted to see if there is interest and/or feedback! Please let me
> know what you think.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *from django.db.models import Fieldfrom django.db.models.lookups import
> In@Field.register_lookupclass IIn(In):"""Case-insensitive version
> of `__in` filters. Adapted from `In` and `IExact` transformers."""
> lookup_name = 'iin'def process_lhs(self, *args, **kwargs):sql,
> params = super().process_lhs(*args, **kwargs)sql = f'LOWER({sql})'
> return sql, paramsdef process_rhs(self, qn, connection):
> rhs, params = super().process_rhs(qn, connection)params =
> tuple(p.lower() for p in params)return rhs, params*
>
> --
> 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/bf623b99-9032-4ada-9739-ef63f2982e6an%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/bf623b99-9032-4ada-9739-ef63f2982e6an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMyDDM2cJ24-mHUAGsADxY9-%3DjR9e56NJ%2BpdAbbDQB33i-D93w%40mail.gmail.com.
Re: custom validation error in password_validators
>
> But it is not possible unless we directly override the
> password_validation classes and this is an extra and dirty work.
I don't think this work is dirty!
We generally prefer to avoid extra settings (and sub-settings) where
possible. The settings file should be clear, and not do what code can do.
So, subclassing here would be the recommended approach, and it already
works with released Django versions.
Moreover, NumericPasswordValidator is a pretty simple class. If you want a
cuostmized version, you’re probably better off copy-pasting the
implementation, and adjusting it as required.
On Mon, Oct 24, 2022 at 7:57 PM Mojtaba Akbari <
mojtaba.akbari.2...@gmail.com> wrote:
> i wanna have custom validation error in password_validators,
> I can do this by rewriting the password validator classes and adding
> desired messages through options in the settings file and the
> password_validat section.
>
> something like this :
>
> AUTH_PASSWORD_VALIDATORS = [
> {
> 'NAME':
> 'django.contrib.auth.password_validation.NumericPasswordValidator',
> 'OPTIONS': {
> 'validation_error': 'My Custom Validation Error.',
> },
> },
> ...
> ]
>
> and so on.
>
> Apart from that I want to return custom validation error, for example in
> our company project we want to send our language based message without
> enabling t10n and l18n. Or ux writer wants to show the user the desired
> error according to business needs,
> But it is not possible unless we directly override the password_validation
> classes and this is an extra and dirty work.
>
> Is it worth the time? After spending some time, can I make a pull request?
>
> --
> 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/1038c5e4-1d86-4c50-90e2-2df7b8c9894dn%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/1038c5e4-1d86-4c50-90e2-2df7b8c9894dn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMyDDM3mkhPYyS1h__koNJUD45pzYA2pVo6sCrvY8GxQv6E3Qw%40mail.gmail.com.
Re: Static files is not loading while deploying the project to AWS ec2
django-developers is not a support channel. Email support requests to *only* django-users. On Sat, Nov 5, 2022 at 7:34 AM Nishant Sagar wrote: > Hi all, > > I deployed the django project to AWS ec2 instance using nginx and gunicorn > but the static file is not loading at all. > > Can someone suggest where did I do wrong? > > Note - I've not created Profile before deploying > > Here is my settings.py file > STATIC_URL = 'static/' > STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles') > STATICFILES_DIRS = (os.path.join(BASE_DIR, 'static'),) > > Project URl - http://54.242.38.208/ > Github- https://github.com/Nishant-Sagar/BaskinSolar > > Thank you for your help, > Nishant > > > > > > > > -- > 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/CANNtL-K_ntgKNAYUd8DHe8wa4bGwHO5da%3DypJfAVN%3DJHj9uCmQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CANNtL-K_ntgKNAYUd8DHe8wa4bGwHO5da%3DypJfAVN%3DJHj9uCmQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM2JRZuTBz-fF8b8K-66dgNrohWauUcFzuf14R%3D_KfKmMw%40mail.gmail.com.
Re: Advancing the "content negotiation" and "modernising request object" proposals.
the deprecation period. (Given the behaviour >> change, and django-upgrade ongoing development, I'd lean now toward >> removal, I >> think.) >> >> In order to get this done, I'd like to introduce this **without also >> solving the pluggable parsers issue** in the first version. >> >> That is, I would like to add `request.data` to provide parsed data from >> the request body, for all request methods, together with `application/json` >> content type handling (and multipart parsing for `application/json` parts >> as well) **but** I would like to leave the configurable parsers step for a >> later iteration. >> >> I think this would give most of the benefit, and allow us to (finally) >> make forward steps here. My hope it that this is addressable before the 4.2 >> feature freeze in January, but if not, OK, it hits 5.0 — at least it's in. >> >> Folks needing other content types can parse request.body as they'd need >> to do now. >> Having a list of request.parsers, configurable in e.g. View.setup(), or a >> middleware, or even a custom request class — essentially at any point >> before accessing request.data — would be the follow-up. Clearly, this would >> be good to have, but I feel like we've blocked on it so long, finding a way >> forward that allows it to be deferred would be sensible. (Prefetch >> evolved...) >> >> Matching ``request.data``, if Adam will pick it up, the modernised >> request API would be >> delightful. (The schedule leaves room for the code changes to come before >> the >> documentation updates if needed.) >> >> >> Does this seem like a reasonable plan? Thanks >> >> >> Kind Regards, >> >> Carlton >> >> >> -- > 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/daff8eee-3d35-45e4-83fe-98d6676b813an%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/daff8eee-3d35-45e4-83fe-98d6676b813an%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM0tGNGZd5Rkb3xU2eVVP9m8zwRc1AvpffuY0bdh0rNVJw%40mail.gmail.com.
Re: Advancing the "content negotiation" and "modernising request object" proposals.
ture needed to pay for the change. >>>> >>>> [2]: >>>> https://groups.google.com/g/django-developers/c/Kx8BfU-z4_E/m/lFXTF0IMCQAJ >>>> [3]: https://code.djangoproject.com/ticket/32259 >>>> [4]: >>>> https://forum.djangoproject.com/t/technical-board-vote-on-ticket-32259-modernize-request-attribute-names/10255 >>>> >>>> Digging further into the history, with a mind to move these issues >>>> forward, having **not** merged Adam's patch first time gives us the needed >>>> pathway forward, I hope. >>>> >>>> I think there have been two reasons the content negotiation suggestion >>>> has not progressed: >>>> >>>> 1. It's been all or nothing. Numerous times it's been requested to >>>> **just** add JSON handling, but that's been bounced back to the full >>>> proposal, adding customisable parsers and so on, which has then >>>> stalled.[5][6] >>>> >>>> [5]: https://code.djangoproject.com/ticket/27415 >>>> [6]: https://code.djangoproject.com/ticket/32646 >>>> >>>> 2. There's a backwards compatibility concern, particularly with >>>> multipart request bodies, where currently you'd get a string, which you'd >>>> then try to parse yourself, not expecting an already parsed dictionary, for >>>> example.[7] >>>> >>>> [7]: https://code.djangoproject.com/ticket/28678 >>>> >>>> The way around the backwards compatibility concern is to introduce a >>>> new code >>>> pathway at `request.data` that handles things in the new way, whilst >>>> deprecating `request.POST`, which could either be removed or become an >>>> alias to >>>> `request.data` at the end of the deprecation period. (Given the >>>> behaviour >>>> change, and django-upgrade ongoing development, I'd lean now toward >>>> removal, I >>>> think.) >>>> >>>> In order to get this done, I'd like to introduce this **without also >>>> solving the pluggable parsers issue** in the first version. >>>> >>>> That is, I would like to add `request.data` to provide parsed data from >>>> the request body, for all request methods, together with `application/json` >>>> content type handling (and multipart parsing for `application/json` parts >>>> as well) **but** I would like to leave the configurable parsers step for a >>>> later iteration. >>>> >>>> I think this would give most of the benefit, and allow us to (finally) >>>> make forward steps here. My hope it that this is addressable before the 4.2 >>>> feature freeze in January, but if not, OK, it hits 5.0 — at least it's in. >>>> >>>> Folks needing other content types can parse request.body as they'd need >>>> to do now. >>>> Having a list of request.parsers, configurable in e.g. View.setup(), or >>>> a middleware, or even a custom request class — essentially at any point >>>> before accessing request.data — would be the follow-up. Clearly, this would >>>> be good to have, but I feel like we've blocked on it so long, finding a way >>>> forward that allows it to be deferred would be sensible. (Prefetch >>>> evolved...) >>>> >>>> Matching ``request.data``, if Adam will pick it up, the modernised >>>> request API would be >>>> delightful. (The schedule leaves room for the code changes to come >>>> before the >>>> documentation updates if needed.) >>>> >>>> >>>> Does this seem like a reasonable plan? Thanks >>>> >>>> >>>> Kind Regards, >>>> >>>> Carlton >>>> >>>> >>>> -- >>> 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-develop...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/daff8eee-3d35-45e4-83fe-98d6676b813an%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/daff8eee-3d35-45e4-83fe-98d6676b813an%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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/294ee7a7-de94-4e47-a7ec-0ac3510ce52dn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/294ee7a7-de94-4e47-a7ec-0ac3510ce52dn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM1dt%3DCayWvj%3D8V0ZHy0C8YY9kDB%3D3Mrkg%3D2cpU5P_Vkaw%40mail.gmail.com.
Re: Advancing the "content negotiation" and "modernising request object" proposals.
;> [1]: https://code.djangoproject.com/ticket/21442 >>>>> >>>>> The second Adam Johnson proposed 2020, and was nearly merged bar >>>>> Mariusz >>>>> **blinking** at the size of the distruption, particularly for >>>>> documentation >>>>> throughout the community, for no change in behaviour. [2][3] >>>>> >>>>> There was an inconclusive discussion about whether we right there[4] >>>>> but, at the time I linked the modernisation to the content negotiation >>>>> issue, as the feature needed to pay for the change. >>>>> >>>>> [2]: >>>>> https://groups.google.com/g/django-developers/c/Kx8BfU-z4_E/m/lFXTF0IMCQAJ >>>>> [3]: https://code.djangoproject.com/ticket/32259 >>>>> [4]: >>>>> https://forum.djangoproject.com/t/technical-board-vote-on-ticket-32259-modernize-request-attribute-names/10255 >>>>> >>>>> Digging further into the history, with a mind to move these issues >>>>> forward, having **not** merged Adam's patch first time gives us the >>>>> needed >>>>> pathway forward, I hope. >>>>> >>>>> I think there have been two reasons the content negotiation suggestion >>>>> has not progressed: >>>>> >>>>> 1. It's been all or nothing. Numerous times it's been requested to >>>>> **just** add JSON handling, but that's been bounced back to the full >>>>> proposal, adding customisable parsers and so on, which has then >>>>> stalled.[5][6] >>>>> >>>>> [5]: https://code.djangoproject.com/ticket/27415 >>>>> [6]: https://code.djangoproject.com/ticket/32646 >>>>> >>>>> 2. There's a backwards compatibility concern, particularly with >>>>> multipart request bodies, where currently you'd get a string, which you'd >>>>> then try to parse yourself, not expecting an already parsed dictionary, >>>>> for >>>>> example.[7] >>>>> >>>>> [7]: https://code.djangoproject.com/ticket/28678 >>>>> >>>>> The way around the backwards compatibility concern is to introduce a >>>>> new code >>>>> pathway at `request.data` that handles things in the new way, whilst >>>>> deprecating `request.POST`, which could either be removed or become an >>>>> alias to >>>>> `request.data` at the end of the deprecation period. (Given the >>>>> behaviour >>>>> change, and django-upgrade ongoing development, I'd lean now toward >>>>> removal, I >>>>> think.) >>>>> >>>>> In order to get this done, I'd like to introduce this **without also >>>>> solving the pluggable parsers issue** in the first version. >>>>> >>>>> That is, I would like to add `request.data` to provide parsed data >>>>> from the request body, for all request methods, together with >>>>> `application/json` content type handling (and multipart parsing for >>>>> `application/json` parts as well) **but** I would like to leave the >>>>> configurable parsers step for a later iteration. >>>>> >>>>> I think this would give most of the benefit, and allow us to (finally) >>>>> make forward steps here. My hope it that this is addressable before the >>>>> 4.2 >>>>> feature freeze in January, but if not, OK, it hits 5.0 — at least it's >>>>> in. >>>>> >>>>> Folks needing other content types can parse request.body as they'd >>>>> need to do now. >>>>> Having a list of request.parsers, configurable in e.g. View.setup(), >>>>> or a middleware, or even a custom request class — essentially at any >>>>> point >>>>> before accessing request.data — would be the follow-up. Clearly, this >>>>> would >>>>> be good to have, but I feel like we've blocked on it so long, finding a >>>>> way >>>>> forward that allows it to be deferred would be sensible. (Prefetch >>>>> evolved...) >>>>> >>>>> Matching ``request.data``, if Adam will pick it up, the modernised >>>>> request API would be >>>>> delightful. (The schedule leaves room for the code changes to come >>>>> before the >>>>> documentation updates if needed.) >>>>> >>>>> >>>>> Does this seem like a reasonable plan? Thanks >>>>> >>>>> >>>>> Kind Regards, >>>>> >>>>> Carlton >>>>> >>>>> >>>>> -- >>>> 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-develop...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/daff8eee-3d35-45e4-83fe-98d6676b813an%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/django-developers/daff8eee-3d35-45e4-83fe-98d6676b813an%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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-develop...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/294ee7a7-de94-4e47-a7ec-0ac3510ce52dn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/294ee7a7-de94-4e47-a7ec-0ac3510ce52dn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/3772a095-6dfa-4e6a-81db-1146d16b3d17n%40googlegroups.com.
Re: Suggestion: Limit activated languages to settings.LANGUAGES
or its apps (but >> not, AFAICT, the setting). d.u.translation.get_language_from_request() >> and get_language_from_path() do check the LANGUAGES setting. It is >> likely that including the check in activate() will do some double work. >> And yet, we found ourselves introducing the security fix. >> >> (I should note that this suggestion was also, independently, raised by >> Benjamin who reported the vulnerability) >> >> Opinions, suggestions, and explanations of the value I miss in allowing >> activate() to take random language codes welcome. >> >> Thanks, >> Shai. >> >> -- >> 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/20221004170511.4342ebc7.shai%40platonix.com >> . >> > -- > 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/CABD5YeGxg1ogazpQE2YqAVq_P8RbhDSK0UPfw2yy6oc%3DUOjWow%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CABD5YeGxg1ogazpQE2YqAVq_P8RbhDSK0UPfw2yy6oc%3DUOjWow%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM2Td9f62rn2MEpoNKY-BCdgGCfjS0Q-JdJFGKK-9x1rJw%40mail.gmail.com.
Re: ModelForm fields localization
Christian - did you end up making a docs PR here?
I’m afraid I don’t really know why fields aren’t localized by default. If
you have a proposal to change this in a backwards-compatible, low
disruption way, that could be easier to discuss.
On Mon, Sep 5, 2022 at 9:23 PM Christian González <
christian.gonza...@nerdocs.at> wrote:
> Hi devs,
>
> just stumbled upon a small (docs?) issue: at
>
> https://docs.djangoproject.com/en/4.1/topics/forms/modelforms/#enabling-localization-of-fields
> , there is an example of how to use that feature. but copy'n'pasting
> that, it won't work, as "fields" is stilla required attribute in the
> Meta class.
>
> For someone not knowing that before this is a bit cumbersome - even me
> as someone who deals quite a long time with Django, I was wondering why
>
> 1. ModelForms do not translate their fields
> 2. the docs don't make clear that localized_fields does not *replace*
> the fields attr.
>
> So I suggest to add a line to the documentation:
> fields = ("birth_date",)
> This fixes 2)
>
> I, for myself, would even go further and deprecate localized_fields - as
> this should be the normal behaviour. ModelForm SHOULD translate model
> labels as default, and a not_localized_fields = [...] (better name?)
> could satisfy the use cases where fields should NOT be localized - which
> are IMHO the minor part.
> This would certainly break things, and I know (and appreciate) your
> conservative approach in Django development.
>
> I found an old ticket: https://code.djangoproject.com/ticket/13546 Where
> this was discussed. But there the "localized_excluded" option was
> suggested additionally to "localized_fields", which overcomplicates
> things and dowsn't make sense. But reversing the logic completely would
> make more sense IMHO.
>
> But maybe I just didn't understand why ModelForm does NOT localize
> fields in the first place per default. You may have a good reason for that.
>
> Christian
>
> --
> Dr. Christian González
> https://nerdocs.at
>
> --
> 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/dd89fee6-0b5a-0a24-5b0e-35e5e7526a20%40nerdocs.at
> .
>
--
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/CAMyDDM1XfAKbyROv_mGdsdZ0HidvqrKqFBJrL9iwmuXn4E-DXA%40mail.gmail.com.
Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.
ent on scope, > so it's better to live as a third-party package. > > - I've tried to include folks from the wider ecosystem in previous years. > Two years ago > we had both Wagtail and django-stubs projects. Wagtail then (last year) > applied in their own right, to great success. I'd like to offer that help > again to e.g. Jazzband or other established projects, assuming > maintainers > feel they have the capacity to mentor. (It's a minor increment to my > effort > for a good return I think.) > > > No urgency but, can I ask you to put your grey cells into action? 🙂 > > > Thanks. > > Kind Regards, > > Carlton > > -- > 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/2b3650c6-d340-4464-96f2-e6722a8e415an%40googlegroups.com > <https://us-east-2.protection.sophos.com?d=google.com&u=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzLzJiMzY1MGM2LWQzNDAtNDQ2NC05NmYyLWU2NzIyYThlNDE1YW4lNDBnb29nbGVncm91cHMuY29tP3V0bV9tZWRpdW09ZW1haWwmdXRtX3NvdXJjZT1mb290ZXI=&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=aUNXTlZRSWRvYVRna24zYXRTMnp5TFdibjZrWmFrdWVGbkhYZWV0NFRSZz0=&h=c7287be4d6014d549d93a7795f9c8969&s=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg> > . > > -- > 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/CAJwKpyRrTuPODiROeLj2wCeROdBPLaFoVXoX%3Da8Be%2BVgbJhw0w%40mail.gmail.com > <https://us-east-2.protection.sophos.com?d=google.com&u=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzL0NBSndLcHlSclR1UE9EaVJPZUxqMndDZVJPZEJQTGFGb1ZYb1glM0RhOEJlJTJCVmdiSmh3MHclNDBtYWlsLmdtYWlsLmNvbT91dG1fbWVkaXVtPWVtYWlsJnV0bV9zb3VyY2U9Zm9vdGVy&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=MVBqeXRyMlJsZGFoTDFUUDgyVTUyTm82L3NaaEdRSXpRWFJzeDIrMFRibz0=&h=c7287be4d6014d549d93a7795f9c8969&s=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg> > . > > -- > 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/abe04f8ef6514d41bdb7c15d6adeeaf0%40Exchange.ISS.LOCAL > <https://groups.google.com/d/msgid/django-developers/abe04f8ef6514d41bdb7c15d6adeeaf0%40Exchange.ISS.LOCAL?utm_medium=email&utm_source=footer> > . > -- 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/CAMyDDM0arGht_Y9JjKEsvdR9Zkb67t%3DuKThwisehVESE1gp%3Drg%40mail.gmail.com.
