Re: Python PEP for more convenient HTML generation

Adam Johnson schrieb am Freitag, 11. Juni 2021 um 10:17:02 UTC+2: > Hi Thomas > > As I understand there wouldn't be much required by Django to support this > - just one function. So if it came to Python, I think we'd like to see a > working snippet, maybe in a third party package, before

Python PEP for more convenient HTML generation

. The goal is to have something like the convenient f-string syntax combined with conditional_escape(). The draft is here: Template Literals: https://github.com/guettli/peps/blob/master/pep-.rst I am looking for feedback. Either here or on python-ideas. If Python would implement this PEP

Re: Feature request: Extend Storage.save() to directly save strings/bytes

Adam Johnson schrieb am Donnerstag, 18. Februar 2021 um 10:04:01 UTC+1: > Hi > > If you're mocking away the storage class to speed up your tests, instead > try this in-memory storage class which implements the complete API: > https://github.com/waveaccounting/dj-inmemorystorage . Then you

Feature request: Extend Storage.save() to directly save strings/bytes

To save strings/bytes you need to use ContentFile up to now: path = default_storage.save('path/to/file', ContentFile(b'new content')) Docs: https://docs.djangoproject.com/en/3.1/topics/files/#storage-objects Things would be bit easier, if save() would support strings/bytes directly. This

Consensus about visual diagrams in the docs.

I once created a simple ascii diagram to explain details of the Django ORM: https://code.djangoproject.com/ticket/27936 Years ago it took some time for me to understand it. And since then it came up by new comers in our team several times. There is agreement on the goal: yes, a visual

Status of "Replacing get_absolute_url()"

I think this page is outdated: https://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl At the top: > This page is a work in progress - I'm still figuring out the extent of the problem before I start working out a solution. No changes since 8 years. Can someone please update the page?

Re: Deprecate is_superuser, is_staff and is_active

Thank you for the inspiring conversation. Am Dienstag, 28. März 2017 14:31:33 UTC+2 schrieb Melvyn Sopacua: > > > > > From an object perspective, you need to send the invoice to the group > "Approvers". Again, best solved at the group level. > > And it's questionable if superusers should be

Re: Deprecate is_superuser, is_staff and is_active

Am Montag, 27. März 2017 16:11:06 UTC+2 schrieb Melvyn Sopacua: > > On Friday 24 March 2017 04:31:32 guettli wrote: > > > I know this is a crazy idea, and it will get the "won't fix" tag very > > > soon. > > > > > > Nevertheless I want to sp

Re: Deprecate is_superuser, is_staff and is_active

Am Freitag, 24. März 2017 14:12:44 UTC+1 schrieb Collin Anderson: > > Hi Thomas, > > "If the user should have all permissions, then why not give him all these > permissions at database level?" - I have some use cases where there are > only 3-5 people that need to log into the admin. I don't

Re: Deprecate is_superuser, is_staff and is_active

Am Freitag, 24. März 2017 13:41:10 UTC+1 schrieb Tim Graham: > > I don't think the current fields are so bad or nonsensical that it > warrants a change. Also, consider that every Django user would have to > learn how to use a new permissions setup. > > If you don't like the default permissions

Re: Deprecate is_superuser, is_staff and is_active

Am Freitag, 24. März 2017 12:42:03 UTC+1 schrieb Andrew Ingram: > > I've always felt that `is_staff` should be changed to a permission such as > `can_access_admin` provided by the Admin app itself. > > However, `is_superuser` is slightly different, in that it's not a > permission, but

Deprecate is_superuser, is_staff and is_active

I know this is a crazy idea, and it will get the "won't fix" tag very soon. Nevertheless I want to speak it out. My use case: Get a queryset of users who have a given permission. I would like to get this with a simple SQL statement. At the moment this query is complex and results in

Re: Autocomplete in Django 1.11: Widget in Forms Library?

eptember 20, 2016 at 6:51:24 AM UTC-4, guettli wrote: >> >> I am happy that there will be support for autocomplete in the admin in >> 1.11, if this issue/pull-request gets resolved: >> >> https://code.djangoproject.com/ticket/14370 >> >> https://gith

Template Tag `url` returns empty string, does not raise NoReverseMatch

If you use this syntax, then no NoReverseMatch exception gets raised: {% url 'some-url-name' arg arg2 as the_url %} This is documented here: https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#url > This {% url ... as var %} syntax will not cause an error if the view is > missing. >

Re: ***SPAM*** Re: Middleware+Transactions:

Am Dienstag, 10. Mai 2016 02:07:30 UTC+2 schrieb Kevin Tran: > > Thomas, did you ever find a solution to your problem? I'm having similar > thoughts and am looking for an answer. > > Carl Meyer has worked out an enhancement proposal, here is the pull-request:

Re: Decoupling Permission-Check from Calling the View

Am Dienstag, 26. April 2016 16:27:32 UTC+2 schrieb Alasdair Nicol: > > I haven't needed to explain why permission has been granted, but I have > had admins asking me why a user is getting permission denied for a > particular view. To answer that, you would > > 1. Get the url > 2. Resolve that

Decoupling Permission-Check from Calling the View

I would like to decouple the permission checking in django. Current draw-back: If you use decorators like [login_required][1], then you can't know in advance whether a user has the permission to do so or not. I would like to split this into two steps: 1. check permissions 1. call the view.

Re: Status of DEP 0005: Improved middleware?

to be completed. > > On Tuesday, March 15, 2016 at 10:32:15 AM UTC-4, guettli wrote: >> >> I like the improved middleware proposal: >> https://github.com/django/deps/blob/master/draft/0005-improved-middleware.rst >> >> What is the status of it? >> >> Is there

Status of DEP 0005: Improved middleware?

I like the improved middleware proposal: https://github.com/django/deps/blob/master/draft/0005-improved-middleware.rst What is the status of it? Is there an agreement under the django-core developers that the proposal is the right direction? Regards, Thomas Güttler -- You received this

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

-framework links to third party extensions in its >> documentation and this had a positive effect on the whole DRF ecosystem. >> >> Federico >> >> >> On Monday, February 1, 2016 at 10:39:44 AM UTC+1, guettli wrote: >>> >>> This ticket was clo

Links from django docs to djangopackages.com should be 'officially endorsed' or not?

This ticket was closed as invalid: https://code.djangoproject.com/ticket/26159 {{{ Here comes a pull request to add a link to the djangopackages comparison grid "Pagination". Background: The pagination in django core is only very basic. Most people want more. I think re-use helps more then

Re: "Project" vs "App"

y. This should be avoided. See https://en.wikipedia.org/wiki/Circular_dependency That's why I vote for "An app must not depend on a project". Thank you Collin for your feedback. I still hope some other people join this thread. Regards, Thomas > > On Thu, Nov 19, 2015 at 4:

"Project" vs "App"

I created a ticket to find a better definition of "Project" vs "App" https://code.djangoproject.com/ticket/25748 I am happy since Tim Graham accepted it. Here are the current docs: https://docs.djangoproject.com/en/1.8/ref/applications/#projects-and-applications Here is my view of Project" vs

Re: #25582: Add a way to build URLs with query strings

> and pass them to the template. (I don't keep the "page" key in "params", > because I want that to reset when filtering or sorting.) > > > > I can remove keys like so: > Show All > > On Friday, October 23, 2015 at 3:41:42 AM UTC-4, guettli wrote: &g

Re: #25582: Add a way to build URLs with query strings

t; On Friday, October 23, 2015 at 3:41:42 AM UTC-4, guettli wrote: >> >> From https://code.djangoproject.com/ticket/25582 >> >> {{{ >> >> It is a common question on stackoverflow and other places: >> >> How to reverse() to url including GET

#25582: Add a way to build URLs with query strings

>From https://code.djangoproject.com/ticket/25582 {{{ It is a common question on stackoverflow and other places: How to reverse() to url including GET parameters? Example: .../myview?foo=bar ​

Re: create_permisions(): Call to ContentType.objects.clear_cache() missing

Am Donnerstag, 20. August 2015 13:14:21 UTC+2 schrieb Tim Graham: > > Hi Thomas, As indicated by the flags on the ticket, it "Needs tests" in > order to be committed. > > On Thursday, August 20, 2015 at 5:31:46 AM UTC-4, guettli wrote: >> >> There is a six year

Re: Why deprecate the ability to reverse using the Python path?

: Please think about this decision again. I guess many people don't want to reformat their code base just because some said it was "just a bad idea". Regards, Thomas Güttler Am Mittwoch, 15. April 2015 10:19:47 UTC+2 schrieb guettli: > > Today I realized that the ability to reverse usin

Re: Why deprecate the ability to reverse using the Python path?

pril 15, 2015 at 4:19:47 AM UTC-4, guettli wrote: >> >> Today I realized that the ability to reverse using the Python path gets >> deprecated >> >> My source: >> https://docs.djangoproject.com/en/1.8/ref/urlresolvers/#reverse >> >> Imagine you hav

Why deprecate the ability to reverse using the Python path?

Today I realized that the ability to reverse using the Python path gets deprecated My source: https://docs.djangoproject.com/en/1.8/ref/urlresolvers/#reverse Imagine you have a very clear directory structure and everyone knows this in your company. The name of an url pattern is redundant. I

Re: Debugging Django

a lot of information if DEBUG=True is set in settings.py. Or: you can set up the logging module and add lines like logging.info("foo: %s" % (foo)) into the code. If you are new to python and django, you can ask on the user mailinglist first. Thomas -- Thomas Guett