Re: Deprecate HttpRequest.is_ajax

If possible, could the logic determining "the best match for your options" be overridable? That way standard implementation would cater for 80/20 and everyone would still have an option to customise further. LP, Jure On 21/11/2019 02:22, Matemática A3K wrote: On Wed, Nov 20, 2019 at

Re: Forms submitted by bots

We're using django-recaptcha (google recaptcha) and it requires a single checkbox click for most "ordinary" users. Some do have to go through a more complex image-identification process, but that one is a few seconds, not 30. Lp, Jure On Sat, 14 Dec 2019, 14:29 אורי wrote: > Hi, > > I'm

Re: Deprecate HttpRequest.is_ajax

hoping to point out the challenges involved. LP, Jure On 20/11/2019 02:17, Matemática A3K wrote: On Tue, Nov 19, 2019 at 9:20 PM Matemática A3K mailto:matematica@gmail.com>> wrote: On Tue, Nov 19, 2019 at 1:29 PM Jure Erznožnik mailto:jure.erznoz...@gmail.com>> w

Re: Deprecate HttpRequest.is_ajax

Sorry for barging in like this, but this is actually a problem I have been dealing with quite a bit lately, so: In my work I very often have to decide, depending on what's calling, what the rendered output might be. Ultimately I went with DRF and its content negotiation, though even that one

Re: python-memcached is deprecated, but still used in core Django

I am currently attempting to involve myself more into Django development. Have little to no idea how. This seems to me like an easy pickings and I would be willing to port existing code to the new package, if that's okay with the core team. My expected approach: 1. verify claims 2. take

Re: Deprecate HttpRequest.is_ajax

>> "I want A, B, C or D - I can give you B or D - Then D - OK" Yes, this. As long as I have the chance to determine B & D BEFORE the content negotiation is complete. As opposed to having them fixed in code by e.g. specifying to_json & to_html methods. LP, Jure On 22/11/2019 02:04,

Extent of async integration into 3.0

I've been monitoring this list for a bit, enough to see that 3.x is now moving in the async direction. Is there a roadmap as to where we want to get with this direction? Or, to ask more directly: I have been looking into django-channels for a while in order to start catering for

Re: Extent of async integration into 3.0

n Schiff asked about "customizable urlize"? On Tuesday, January 7, 2020 at 1:55:00 PM UTC+1, Jure Erznožnik wrote: I've been monitoring this list for a bit, enough to see that 3.x is now moving in the async direction. Is there a roadmap as to where we w

Re: Psycopg3 Redesign

His proposed changes look awesome to me! IMHO, the biggest issue going async with current implementation was connection pooling for async code. I feared that we might need huge numbers of connections in certain scenarios, especially if the code required altering the connections themselves.

Re: Adding ability to choose AutoField type (signed vs unsigned)

Sorry if I understand stuff incorrectly, but: I agree with Adam where he discusses migration issues, but I also don't see how "DEFAULT_AUTOFIELD" setting could leave tables out of the migration(s). My understanding is that it would cause immediate re-provisioning of all the pk fields,

Re: Adding ability to choose AutoField type (signed vs unsigned)

I would like to try again: I believe having a general setting for autofields could cause all sorts of issues. As illustrated, I immediately thought that some people might want to use that for migrating to UUID fields for that (I read about using them somewhere about when I started using Django 5

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

I too am in favour of this change. But I read Andrew's comment differently: it's maybe not the 60 characters, but some sort of "aggregation" we could be looking for. So maybe instead of "0026_remove_book_title_add_book_description" we could have "0026_book_add_remove" - especially when

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

I agree. If anything, I've always had issues with GET & POST being different entities in the first place, but never with their names. I would really like to see an entity combining both of them. THAT one, maybe the preferred way of doing so, would be lowercase, but RAW representations of

Re: Best Practices Creating a User

I think you found the wrong mailing list for this question. Might I suggest you try django-us...@googlegroups.com? The question seems better suited there. LP, Jure On 05/05/2020 14:47, 'Debjyoti Biswas' via Django developers (Contributions to Django itself) wrote: Hi I am a new Django

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

Sorry guys for asking a really stupid question, but : I just made a search for pytz in Django master and found 17 occurrences in 5 files. More in docs and tests though. But still. Isn't what we're debating here moot since Django itself doesn't really depend on pytz all that heavily? I mean,

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

I would definitely be in favor of an opt-in: it would give developers time to move to the new system at their convenience. Example: we're about to try and tackle the TZ issue in our apps and we want to do it "globally" with one definitive solution. I'd much rather do it on a library that is

Re: Cache framework

May I ask where that survey was conducted? I totally missed it. LP, Jure On 18/08/2020 15:33, Carlton Gibson wrote: I think we SHOULD bring a redis cache backend into core. The recent survey showed 70% of our users using redis for caching, with 20%+ using memcached. Nick is working on

Re: include_block template tag

then it will be difficult to get this into core without the championing from a core developer. If there was enough interest I would certainly be happy to contribute to the feature! Sam On Monday, August 17, 2020 at 10:05:29 AM UTC+1, Jure Erznožnik wrote: While rendering templates we often come

Re: include_block template tag

It definitely does. Thanks. Jure On 19/08/2020 14:03, Carlton Gibson wrote: From the thread, I’d suggest collaboration with Curtis if the ideas are similar enough. Also from the thread: the idea seems to fit between include as we have it now, and a custom tag. Maybe that gap hasn’t been

Cache framework

Apologies for wall of text, but it's a complex issue I'm raising. Hopefully you will see something you thought about in the recent past. I have also indented the rationalisation part, so if it's TL;DR, don't read it. Well, on with it: I've lately had some dealings with Django caching

include_block template tag

While rendering templates we often come into situations where data remains the same, but sometimes we want to render it one way, other times - another. Examples: a library supporting various CSS frameworks. You would always render panel

Re: Instance Based Management?

Hi Matthew, I think you found the wrong mailing list for this question. Might I suggest you try django-us...@googlegroups.com? The question seems better suited there. That said, I don't know why you wouldn't want to use foreign keys in this scenario, but Django does support a thing called

Re: Welcome email

+2 m...@kye.id.au wrote: > This issue is exacerbated by similarly unaware / uncaring mailing list > users responding to support requests. > > What is the best path forward here? > > On 10 Jul 2020, at 3:09 pm, Jure Erznožnik wrote: > >  > > I too volunteer for the

Re: Critical hints about Django migrations

It seems to me that article is written by a guy who has a lot of knowledge of the database engine and has some issues (mostly) with Django migrations system. His solution to the problem is to use direct SQL statements which of course can be more finely controlled than whatever Django creates.

Re: Welcome email

I too volunteer for the screening job. LP, Jure On 09/07/2020 16:10, Peter Inglesby wrote: Hi folks, Is there any moderation for posts from new users? It can be enabled , and I'd be willing to be part of a team that filters posts from

Re: The blacklist / master issue

+1 on this discussion progression. I too struggled with certain expressions in my earlier English-learning days, but today the used expressions don't carry any unnecessary baggage for me as my understanding of them is purely technical. So, while I myself don't have a problem with them, I can

Re: ./manage.py settings

There was a GSoC proposal this year for a SecretsManager that could conceivably make what you suggest possible. Wasn't accepted though. Not sure if

Re: Suggestion: "django-admin startproject" should not put secrets in settings.py

+1 on this approach. No problems with external storage mechanisms where the newbie then needs to do something to provide the required data. It's all done neatly in Python, but secrets themselves are conveniently placed in a different file. LP, Jure On 26/07/2020 15:09, Roy Smith wrote: In

Re: include_block template tag

Final comment for this: we implemented the tag in our dynamicforms library (commit with initial implementation ). The initial implementation straight-out replaces the django include tag, giving it an

Re: Revisiting Python support for after Django 3.2 LTS

Maybe I'm getting old, but: This is going extremely (too?) fast. I don't think Ubuntu LTS releases provide Python versions in time before the release chosen for the LTS becomes expired. I've definitely had an issue like this with django-channels and its required redis version. So if I choose a

Re: Collectstatic verbosity, again

I'd just like to mention that ManifestStaticFilesStorage doesn't output one line. It will output a line for every file, even if file with that hash already exists. This is without the clear flag. I hope it's relevant to the discussion: seems different storages implement output separately.

Re: Feature request: Template tag like stateless component in JSX React

Source is here (https://github.com/velis74/DynamicForms/blob/master/dynamicforms/templatetags/dynamicforms.py - see at end of file), documentation will follow shortly as we near 1.0 release (right now it's pretty pathetic, but it is there at readthedocs), but there are examples & unit tests

Re: Feature request: Template tag like stateless component in JSX React

Aztec, Just look in the dynamicforms/templates folder: all templates for input fields are built using this tag in its various forms. There's plenty of examples there. And yes, it's exactly what you asked for. LP, Jure On 29. 01. 21 09:18, Aztec Rabbit wrote: Curtis - This is nested block

Re: Feature request: Template tag like stateless component in JSX React

We have just created a tag like that in our dynamicforms library. It's called "extendtemplateblock". Feel free to use or copy, but it doesn't look like it's going to be accepted in Django itself. We tried to keep API similar to the "include" tag, so it should be easy to use. You can choose

Re: include_block template tag

Hi Pierre, I like your solution very much: implements what needs to be implemented, rationalises it very well and also adds all the other bits'n'pieces required for a proper PR. I really hope this gets accepted, it was a huge thorn in our butts until we implemented it. Now we're (ab)using

Re: Developer wanted

I think this is the wrong mailing list to ask questions like that: you should try django forums instead. That said...: We might be interested. Can you share more details? There's no website, but we're doing about ten or so django apps for various purposes. We have 6 years experience with the

Re: #21978 include production-ready web server

IMHO, adding YAML support would introduce a dependency that's not needed: why not just use Python, instead of ini/yaml/toml? Projects could have a (.gitignore) env.py that settings.py imports and then sets the appropriate variables from it. You can use straight assignment, e.g.

Re: Model-level validation

I'd like to chime in with this: There was a point in time when we ran into this issue and solved it with our own Model descendant. IMHO, I'm completely with Aaron on this: all the guts are there, just not being used. It took me quite a while to wrap my brain around the idea that validation

Re: Drop CSRF middleware from the settings template

https://security.stackexchange.com/questions/262245/are-csrf-attacks-a-thing-of-the-past Looks like lax will do the trick, but it's not like there aren't legit cases for same-site policy to be set to something less restrictive. LP, Jure On 17. 04. 23 09:24, Jacob Rief wrote: On Monday,

Re: Drop CSRF middleware from the settings template

OK, I'll bite: For the first issue, my problem revolved around this code: @property def POST(self): # Ensure that request.POST uses our request parsing. if not _hasattr(self, '_data'): self._load_data_and_files() if is_form_media_type(self.content_type): return self._data return

Re: Can we move the activity on this list to the Forum now?

This has been answered affirmatively in this very thread before. The forum even has a "Mailing list mode" in addition to several other mailing options (including a nifty "activity summary"). LP, Jure On 4. 05. 23 07:28, Curtis Maloney wrote: Does the Forum allow me to get email

Re: Feature request: making gettext more robust

The behaviour is the same on Android. iOS makes it more straight-forward because you HAVE TO have all translations in all languages you support. LP, Jure On 15. 06. 23 16:15, Tobias Kunze wrote: On 23-06-15 04:29:59, Gergely Kalmár wrote: It seems that gettext is currently quite permissive –