Re: (Circa end of 2021) Localization issues with input type=date?

[Matthias Kestenholz]

Hi,

On Thu, Nov 10, 2022 at 9:40 AM Jacob Rief  wrote:

> How about ditching the JS based datepicker altogether and replace it
> against the built-in datepicker offered by modern browsers? This would also
> help users of mobile devices because they already have good internal
> implementations to select a date. I agree that on desktop browsers the
> built-in datepicker does not really look nice, but IMO still works way
> better than the  widget, (ab-)used for date types as
> currently implemented in Django.


I'll second this. I'm not sure about ditching custom date pickers on all
public-facing websites (yet) but I think it's definitely a good idea for
administration panels. I have had good success with this in the last years.

The problem (as much too often) is Safari. Safari only has proper support
since 14.1, released only ~18 months ago (https://caniuse.com/input-datetime)
I haven't removed the date-input-polyfill yet. That may be a reason to wait
a bit, sad as it is.


Thanks,
Matthias

-- 
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/CANvPqgA6WQ29aBJ5QFnf7Ygig88%3DYXv-rVU1HgUzXCoK-DQHjA%40mail.gmail.com.

Re: #21978 include production-ready web server

[Matthias Kestenholz]

On Tue, Nov 1, 2022 at 10:34 AM Florian Apolloner 
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)`.
>
>
I found a neat trick in a 12factor library somewhere (I don't remember
where unfortunately) of using ast.literal_eval for config variables:
https://docs.python.org/3/library/ast.html#ast.literal_eval
https://github.com/matthiask/speckenv/blob/94722bcc95b94a9e6b1a1aada2bd977c43bfb767/speckenv.py#L63

This may be too cute or magical for Django. It certainly works well and
avoids having to be overspecific with types. I find it boring to tell the
config loader that True is a bool and "hello" is a string. That being said
I don't really have a strong preference here apart from having a strong
dislike for the "several settings files" pattern. It's much more obvious to
me if e.g. `MIDDLEWARE` is configured in a single location and not modified
in other files.

Thanks,
Matthias

-- 
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/CANvPqgCTFEoO%2BG8-UNmHRPckto0DPoJb5-d596oexAc2kqxtNQ%40mail.gmail.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Matthias Kestenholz]

Hi

I believe the main objection is against adding additional API to querysets.
get_object_or_404 only converts DoesNotExist into a 404 exception and
doesn't handle MultipleObjectsReturned.

I'm not the first to suggest adding an additional shortcut, e.g.
django.shortcuts.get_object_or_none which would work similarly to
get_object_or_404 (and get_list_or_404 for that matter). The existing
shortcuts use functionality from several parts of Django (the ORM and the
request/response handling) which get_object_or_none wouldn't do, but its
behavior would be so close to what get_object_or_404 is doing that it may
be alright.

OTOH even the implementation of this shortcut is so simple that I just add
it to each project when I have a need for it (I had a hard time finding it
because it comes up much less often than I thought it did). So I am not
proposing this addition personally but I wouldn't be against it either (if
that counts for anything).

Best regards,
Matthias



def get_object_or_none(klass, *args, **kwargs):
queryset = _get_queryset(klass)
if not hasattr(queryset, "get"):
klass__name = (
klass.__name__ if isinstance(klass, type) else
klass.__class__.__name__
)
raise ValueError(
"First argument to get_object_or_404() must be a Model,
Manager, "
"or QuerySet, not '%s'." % klass__name
)
try:
return queryset.get(*args, **kwargs)
except queryset.model.DoesNotExist:
return None



On Sun, Jul 10, 2022 at 10:13 PM Dave Gaeddert 
wrote:

> Fair enough. To me, the `get_or_none` behavior with multiple results would
> still be to raise an exception (so it is just like `get` in that sense).
> And that’s the reason I personally don’t just see it as a shortcut for
> `filter().first()` — I have (as I’m sure others have) made the mistake
> before of *thinking* that I was using a unique query when that wasn’t
> necessarily true, so the multiple results exception has caught mistakes at
> runtime. I’d rather have that exception than use `filter().first()` and
> potentially show the wrong object to the wrong user, for example, and not
> figure out that I have a uniqueness/db problem. I like the fact that `get`
> raises those exceptions, I just think that try/except DoesNotExist/None is
> such a common behavior that a shortcut for *that* would actually be
> useful.
>
> Dave
> On Sunday, July 10, 2022 at 3:24:32 AM UTC-5 Adam Johnson wrote:
>
>> 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-develop...@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
>>> 
>>> .
>>>
>> --
> 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/dbee041d-4f80-4e61-bf0a-1d6f4e2e22e6n%40googlegroups.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/CANvPqgBCDjejMb_QrHpgZ%3DuZanCgCnwYb42-2-Mf8bmQ1cnL%3Dw%40mail.gmail.com.

Re: Proposal on how add configuration options to Email Backends

[Matthias Kestenholz]

Maybe we're doing something stupid or there's a misunderstanding but we had
a recent use case for this: The same website runs on several domains, one
domain per language and each domain has its own email address. We were
using an email relay (Mailgun in this case but the same will probably be
true for Sendgrid, SES etc.) with different authentication parameters for
each sender address.

It wasn't that hard to instantiate one EmailBackend per domain/language but
it would definitely be nice if something like this was supported out of the
box.

Best regards,
Matthias



On Sun, Jan 30, 2022 at 4:39 PM Florian Apolloner 
wrote:

> I do not understand why you would need multiple email backends to send
> from different addresses. Can you elaborate on that?
>
> On Sunday, January 30, 2022 at 1:18:48 PM UTC+1 st...@jigsawtech.co.uk
> wrote:
>
>> I've a big +1 on changing email config to a dictionary to support
>> multiple backends as it's very much a common occurrence for both clients of
>> mine and for my own businesses. Most of the use cases are when they main
>> site sends emails from no-reply@ such as for password resets but then
>> when alternative email are required for sales and/or customer service email
>> address where it's handled via the website. Currently I end up creating a
>> custom settings.py dictionary to store the settings so I can then refer to
>> that using the connection for swapping the backend to send from.
>>
>> On Sunday, 30 January 2022 at 11:14:54 UTC f.apo...@gmail.com wrote:
>>
>>> Hi Jacob,
>>>
>>> I wouldn't be opposed to move email configuration into a dictionary
>>> (somewhere between -0 and +0). Although if we plan to do that we should
>>> rethink all the existing session variables and other as well I guess and
>>> figure out if we should move more settings to dictionaries.
>>>
>>> > why shouldn't it makes sense to have different email backends? If you
>>> have a staging system you may want to use you local SMTP-relay, while in
>>> production
>>> you may for instance use AWSs SES
>>>  service.
>>>
>>> This specific example at hand is imo not a good motivator to add support
>>> for multiple backends because the settings would imo be different. Take
>>> databases as an example: You also don't have staging/production in there
>>> but switch the actual values in the default database.
>>>
>>> > `EMAIL = [...]`
>>>
>>> I am not sure a list makes sense here and would go for similarity with
>>> CACHES & DATABASES since you'd usually identify the backend via a unique
>>> name or so. Also DATABASES & CACHES have an OPTIONS dict which is the
>>> passed on to the backend, I think we should follow suit here.
>>>
>>> > Personally, I would prefer SMTP = {...}
>>>
>>> I do not think SMTP would be a good fit because many services allow HTTP
>>> submission, so what we are sending is actually an email and smtp is just a
>>> protocol implementation in the backend of AWS SES or so.
>>>
>>> As for other email backends that do require different options: I do not
>>> see an issue when they simply take `EMAIL_AWS_SES_KEY` and document it as
>>> such; this doesn't require us to add more flexibility to email backends…
>>>
>>> So I guess it boils down to the following questions:
>>>
>>>  * Do we want to support multiple (at the same time) email backends, if
>>> yes we would move to a settings dict anyways…
>>>  * If the answer to the above is no, what value does putting it into a
>>> single dict give us?
>>>
>>> In the past I think I have argued for a SECURITY_HEADERS (or similar)
>>> dict because it allows us to check the dictionary keys easily for typos;
>>> emails probably don't suffer from that problem as badly as security related
>>> settings.
>>>
>>> I hope this can get the discussion going.
>>>
>>> Cheers,
>>> Florian
>>> On Sunday, January 30, 2022 at 9:29:27 AM UTC+1 jacob...@gmail.com
>>> wrote:
>>>
 Well, that ticket is 8 years old and in the meantime other email
 backends have emerged, requiring different configuration options.
 I made this proposal after attempting to fix a 14 year old open ticket
 #6989 but this was ultimately postponed, see comment by
 Carlton Gibson on
 https://github.com/django/django/pull/13728#issuecomment-987762791

 To summarize the discussion from 7 years ago

 Collin Anderson wrote:

> I don't see any benefit to moving email settings to a dictionary. It
> is helpful for databases and caches because there can be multiple
> backends.

 It makes the popular "from local_settings import *" convention harder
> to use. What's wrong with 6 individual settings? If the goal is to allow

 multiple email backends, then let's make that the ticket goal.


 and Carl Meyer replied:

> I agree with Collin; unless we are adding new capabilities (i.e.
> multiple configured email backends, which it seems nobody really wants),
> 

Re: The blacklist / master issue

[Matthias Kestenholz]

Yes, please.

As a third party app developer I'll have to update a few GitHub 
workflows and tox configurations (since I'm running testsuites against 
the main branch too). It may be useful to announce this change on as 
many channels as possible (mailing lists, the forum, as a news entry on 
the Django website). Just an idea, this shouldn't be a blocker for 
moving forward with this.


Thanks,
Matthias


On 24/02/2021 00:12, 'Adam Johnson' via Django developers (Contributions 
to Django itself) wrote:
Yes, let's do it. I did it to my open source projects a couple weeks ago 
and everything has been smooth since. We'll need some find/replace for 
links in the main repo, on djangoproject.com , 
and I imagine some other places.


On Tue, 23 Feb 2021 at 22:15, Kenneth > wrote:


I agree. We should go ahead and do the switch

On Tue, Feb 23, 2021 at 11:57 AM Markus Holtermann
mailto:i...@markusholtermann.eu>> wrote:

Hi all,

Reviving an old topic. GitHub has by now tooling in place to
rename branches and keep open PRs in sync. In fact, if I were to
change the `master` branch to `main`, GitHub tells me this:

Renaming this branch:
* Will update 158 pull requests targeting this branch across 112
repositories.
* Will update 1 branch protection rule that explicitly targets
master.
* Will not update your members' local environments.

I'd suggest to go through with this change and make the
necessary changes to the CI / website.

Cheers,

Markus


On Tue, Jun 23, 2020, at 11:04 AM, Mark Bailey wrote:
 > +1 on a good decision to make this change.
 >


--
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/81446dcd-e04c-3c28-91b5-a276a38baaf7%40feinheit.ch.

Re: Multi theme support for admin

[Matthias Kestenholz]

Hey,

I'm still working on https://github.com/django/django/pull/13435 , an
attempt to use CSS variables to style the administration interface.
Unfortunately, real life and (desired) deadlines from paid projects tend to
interfere. I still very much intend to clean up the pull request which is
getting quite close to getting merged, I hope.

Your proposal of not only changing colors but allowing different skins
sounds like it would require (much) more effort and probably also more
maintenance down the road. This may be a real world reason why we shouldn't
implement this (I'm not saying it isn't a good idea!)

Best regards,
Matthias

On Mon, Dec 21, 2020 at 6:00 PM Ramez Ashraf  wrote:

> Hello Django Developers list
>
> I'm sending on this thread to hopefully open a discussion about
> *Adding the ability for a multi custom theme in Django's Admin*.
>
> *What do i mean ?*
> We can have many multiple Django admin sites
> <https://docs.djangoproject.com/en/3.1/ref/contrib/admin/#multiple-admin-sites-in-the-same-urlconf>,
> where each site can have its registered models, apps, admin views, etc.. ok?
> However,
> Those different admin sites are limited to one interface/html structure,
> located at `tempates/admin`. A change in one admin site base.html will
> affect the other admin sites.
>
> *Proposal:*
> A way to direct each AdminSite to the template path where it should find
> the templates.
>
> *Example:*
> Add a setting called ADMIN_DEFAULT_THEME = 'admin'
> Add an attribute to AdminSite called theme which default to
> ADMIN_DEFAULT_THEME, and basically this setting controls which directory
> this admin site look for templates.
> So whenever a path like 'admin/some_file_name.html' occurs, it is to be
> replaced with something like f'{admin_theme}/some_file_name.html'
> This will take effect in extends statements, AdminSite templates
> loading(index/app index / etc) and ModelAdmin template loading (change
> form/list/delete etc..)
>
> *Use case:*
> You want to be able to use the django admin default theme along with
> something like django-jazzmin <https://github.com/farridav/django-jazzmin> 
> along
> with Grappelli <https://grappelliproject.com/> or django-suit
> <https://pypi.org/project/django-suit/>.
>
> *Final thoughts:*
> * I see no real reason why we should not implement this.
> * I sits well with the multi admin site idea. If we can have several
> different sites then they should be able to look different .
> * This open the door for admin theme to be something plug and play which
> in my opinion have some interesting nice outcomes
>
> Finally, Thank you for your time reading this and i hope you support it or
> engage in a discussion.
> Looking forward for your replies ..
>
>
> --
> 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/f96a4b22-3ce3-4031-a97a-d3b406d788ccn%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/f96a4b22-3ce3-4031-a97a-d3b406d788ccn%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Feinheit AG - Matthias Kestenholz - Direkt +41 79 444 78 96 - Zentrale +41
555 11 11 41

-- 
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/CANvPqgDFgznQu-zQRnpo5anUDC4B5r2%2Bfq9eZcVgdf6yzci2%3Dw%40mail.gmail.com.

Re: Mechanics of the EmailValidator.domain_allowlist rename.

[Matthias Kestenholz]

Hi

I have survived a few changes in Django over the last >10 years, and this
change is absolutely not comparable to any of the problematic ones.

For example, the get_query_set -> get_queryset rename was hard because it
was unclear how to properly support subclassing querysets.

The on_delete addition was terrible because everything had to be edited by
hand. The time investment is significant even after upgrading dozens of
sites.

The proposed rename can be achieved in projects with a relatively
straightforward invocation of "git grep --name-only domain_whitelist |
xargs sed -i -e s/ domain_whitelist/ domain_allowlist/g". We don't have to
add new arguments by hand or think about subclassing.

In my opinion 1) really is fine in this case. Yes, it will also need a
little bit of time to update this, but it'll be a blip compared to other
problems I'll encounter when the next upgrade comes around.

Thanks,
Matthias

On Thu, Jun 18, 2020 at 5:10 PM Carlton Gibson 
wrote:

> Hi All,
>
> We merged the docs changes remove whitelisted  last week.
> https://github.com/django/django/pull/13031
>
> There's a PR now ready to adjust EmailValidator to use domain_allowlist.
> https://github.com/django/django/pull/13079/
>
> This is all fine *except* it will require editing any historical
> migrations that feature EmailValidator, using the `domain_whitelist`
> attribute, since validators are serialized in migrations.
>
> * Thinking of in user projects, and any third-party apps.
>* An affected third-party would need to think about timing of a change,
> support say 2.2 until EOL. ...
> * Suspecting total number of affected lines is low, but not zero.
> * To begin there's a deprecation period, so plenty of warning, but asking
> people to edit old migrations is not ideal shall we say.
>
> (Hopefully that's not too terse.)
>
> Options:
>
>
> *1. Bite the bullet. *
>
> I'm not too keen on this: `on_delete=models.CASCADE`.
> In the 1.9 release notes there was, "Update models and existing migrations
> to explicitly set the argument."
> It was horrible.
>
> The scale here is not anything like the same but...
>
>
> *2. Don't remove the whitelist kwarg. *
>
> We could just leave it forever, undocumented, commented in the code as
> just an alias to the new domain_allowlist.
>
> If we did this, there's a question as to whether we'd have a warning for
> the kwarg during the deprecation period?
> (If we did, we'd remove the warning, but not the actual kwarg.)
>
> This is horrible too, but given 1 I think we have to consider it.
>
>
> *3. Some kind of script to make the changes for us. *
>
> So I see django-codebump just came up in the BigAutoField thread. Similar
> came up in the Remove url() thread recently.
>
> What's the state of play here? Are we in a position (by 3.2) to ship a
> utility to (*inter alia*) automate updating historical migrations?
> Without having looked into it, this seems like a small, well scoped
> problem, that would make a good test case for such a tool.
>
> In theory this is better that 1 or 2, but is it feasible?
>
> Thoughts?
>
> Thanks.
> 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/05567701-5721-469b-830b-11da4f116d4bo%40googlegroups.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/CANvPqgBJF-weRiYqE5fMwWO1eV02oVwmqDgQPRBo5itynBycww%40mail.gmail.com.

Re: timesince 'depth' parameter

[Matthias Kestenholz]

The same could be said for "1 day, 23 hours" vs "1 day".

The way I implemented it in a former project was to only switch to days
after 48 hours, and/or only switch to years after 24 months etc.

Best regards,
Matthias

On Sat, May 23, 2020 at 12:00 PM Tom Forbes  wrote:

> I like this idea. However while `depth=1` makes sense for shorter time
> periods where the difference between `4 hours` and `4 hours and 3 minutes
> ago` is not required to be displayed, when you get a value that is over a
> year ago it loses a lot of granularity. The difference between `1 year` and
> `1 year and 11 months` is much more important.
>
> In this case you probably want `depth=2` (“1 year, 6 months ago”), but
> only for values over a year ago. Given that, maybe a simple depth flag
> isn’t enough? I think what we really want here is a `compact=True` flag.
>
> On 22 May 2020, at 16:59, Toby Such  wrote:
>
> Hi all!
>
> I've been a little frustrated with the timesince filter that comes with
> default Django. By default it always comes with 2 parts e.g. 4 hours and 3
> minutes ago but I would much rather have just the 4 hours. In my own
> projects I've simply created my own version of the timesince filter and 
> accompanying
> utils function that powers it that just has the code which adds the second
> part removed. However I wonder why this isn't standard as I can't think of
> a single website that displays time since as multiple parts.
>
> I'm proposing adding a 'depth' parameter to the timesince function which
> would allow the developer to set how many parts to render. At depth one it
> would be "3 weeks". 2 depth: "3 weeks 2 days" (default behaviour), 3 depth:
> "3 weeks, 2 days, 4 hours ago" etc.
>
> Does anyone have any thoughts related to this?
>
> --
> 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/97fbcab8-3f0f-4277-9296-fdcff7fcdab5%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/97fbcab8-3f0f-4277-9296-fdcff7fcdab5%40googlegroups.com?utm_medium=email_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/DCC0D41F-A34F-4FFD-B8CC-39988EBE357E%40tomforb.es
> <https://groups.google.com/d/msgid/django-developers/DCC0D41F-A34F-4FFD-B8CC-39988EBE357E%40tomforb.es?utm_medium=email_source=footer>
> .
>


-- 
Feinheit AG - Matthias Kestenholz - Direkt +41 79 444 78 96 - Zentrale +41
555 11 11 41

-- 
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/CANvPqgBMMeFxkyFtk3D1OeafYRKJq2YfBNOP4odwuTsHsuMEkA%40mail.gmail.com.

Re: Proposal: Multiple-Inheritance in Templates

[Matthias Kestenholz]

Hi,

You could make the generic-list.html template extend a configurable base
template, e.g. "{% extends base_template|default:'base.html' %}", and add
context["base_template"] = "orders/base.html" in views belonging to the
orders app, and "products/base.html" in the products app.

I often use this pattern exactly for the case when some app needs to add
its own submenu.

Best,
Matthias



On Tue, Feb 18, 2020 at 9:44 PM Yo-Yo Ma  wrote:

> Please help us all understand, then:
>
> How is it possible to inherit the blocks defined in both the
> orders/base.html template *AND* the generic-list.html template while
> inheriting *only* from the generic-list.html template?
>
> On Tuesday, February 18, 2020 at 3:32:12 PM UTC-5, matthew.pava wrote:
>>
>> I did read your post, and I did come to that conclusion. I may have
>> ultimately misunderstood, and I’ll certainly take the blame for my own
>> misunderstanding. The example you provided can be done without multiple
>> template inheritance. So far, my thoughts on the design concept is that
>> multiple template inheritance is unnecessary.
>>
>>
>>
>> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com]
>> *On Behalf Of *Yo-Yo Ma
>> *Sent:* Tuesday, February 18, 2020 2:25 PM
>> *To:* Django developers (Contributions to Django itself)
>> *Subject:* Re: Proposal: Multiple-Inheritance in Templates
>>
>>
>>
>> @matthew.pava please read the entire OP again.
>>
>>
>>
>> You can't have actually read the post and come to the conclusion that
>> inheriting from generic-list.html would solve the problem.
>>
>>
>>
>> These kinds of "I didn't read it but it looks like you could just X"
>> replies are a big problem in mailing lists; they have the unintended
>> consequence of causing serious posts to like noobie "help me" questions by
>> later passers by.
>>
>>
>>
>> I'm a 12-13 year Python veteran (11 years full-time Django), not a noob,
>> and I think this feature could be a tremendous benefit to Django templates,
>> and I'd like some real thoughts on the design concept.
>>
>>
>> On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
>>
>> In your example, you could just inherit from generic-list.html since it
>> already extends base.html. You would be repeating yourself in your current
>> example.
>>
>>
>>
>> *orders/list.html*
>>
>>
>>
>> {% extends 'generic-list.html' %}
>>
>>
>>
>> {% block list-item %}
>>
>> Order # {{ order.id }} (total: {{ order.total }})
>>
>> {% endblock %}
>>
>>
>>
>>
>>
>> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com]
>> *On Behalf Of *Yo-Yo Ma
>> *Sent:* Sunday, February 16, 2020 10:02 AM
>> *To:* Django developers (Contributions to Django itself)
>> *Subject:* Proposal: Multiple-Inheritance in Templates
>>
>>
>>
>> Please read this in full - you will not be disappointed by the end.
>>
>>
>>
>> We often talk about "multiple-inheritance" when referring to multiple
>> levels of {% extends ... %} and defining {% block ... %} many layers up in
>> base templates.
>>
>>
>>
>> But, something that comes up as a useful idea in my mind on a regular
>> basis when working in Django templates is the ability to actually inherit
>> from multiple base templates.
>>
>>
>>
>> The immediate reaction to this idea might be repulsion until you think
>> through the implications and weigh them against the benefits.
>>
>>
>>
>> An example (simplified) use case speaks louder than explanation:
>>
>>
>>
>> *base.html*
>>
>>
>>
>> Some top-level menu
>>
>> {% block submenu %}{% endblock %}
>> {% block content %}{% endblock %}
>>
>>
>>
>> --
>>
>>
>>
>> *orders/base.html*
>>
>>
>>
>> {% extends 'base.html' %}
>>
>>
>>
>> {% block submenu %}
>>
>> View all Orders
>>
>> Enter an Order
>> {% endblock %}
>>
>>
>> --
>>
>>
>>
>> *products/base.html*
>>
>>
>>
>> {% extends 'base.html' %}
>>
>>
>>
>> {% block submenu %}
>>
>> View all Products
>>
>> Create a Product
>> {% endblock %}
>>
>>
>> --
>>
>>
>>
>> So, we have a relatively common template setup, with some apps defining
>> their own base templates that extend the main base template, and then
>> defining their own submenus, etc.
>>
>>
>>
>> At this point, we know there will be a product list page and an order
>> list page, but we also know that the product list template will extend the
>> product base template and the order list template will extend the order
>> base template; same goes for the product create and order create, both also
>> extending their respective apps' base templates.
>>
>>
>>
>> This means duplication. The product list template will contain most of
>> the same list-related HTML, etc. as the order list, but the only way to
>> avoid that duplication will be to make a base list template and extend that
>> template from both the product list and order list.
>>
>>
>>
>> *generic-list.html*
>>
>>
>>
>> {% extends 'base.html' %}
>>
>>
>>
>> {% block content %}
>>
>> 
>>
>> {% for object in page.object_list %}
>>
>> {% block 

Re: Proposal to format Django using black

[Matthias Kestenholz]

On Wed, Apr 24, 2019 at 9:06 AM Carlton Gibson 
wrote:

> On Wednesday, 24 April 2019 08:58:57 UTC+2, Josh Smeaton wrote:
>>
>> lots of bikeshedding
>>
>
> Yeah. 
>
> But we've already got a style guide, so **IF** we can get a YAPF config to
> work to that then hopefully the arguments against using a formatter here
> would be moot. (Note that **IF** — I only said I'd have a play.)
>
> Equally, **IF** it's true that the Python community is standardising
> around black then, we should join in. But I get the impression that's not a
> done deal yet.
>
> I'm not fussed on the code style. The brain/eye adapts. As I said before,
> I would like us to have an auto formatter of some kind.
>

It's maybe not fair to count all channels-related repositories
individually, but when I take a look at the code repositories in the Django
organization on Github I see either repositories using only flake8/isort or
repositories using black. One could say that the Django organization
already is moving towards standardizing on black...

The arguments against a particular code style will never stop. In this case
it's a big advantage to choose a tool developed by others which does not
allow any bikeshedding.

I can see why one would want to wait on others to choose a standard tool
for the Python community. On the other hand, Django could easily help
establish the "obvious way to do it" given its visibility.

-- 
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/CANvPqgAzG3YUhOKD4003WF0PwXJ3xKUEAhJYfr-%2BoHuGE8C00w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Matthias Kestenholz]

After dozens of mails it's clear that this is certainly a controversial
topic -- especially, as always, string quoting.

I think there is an overwhelming benefit in adopting black and not
deviating from the defaults even if the only benefit of this is just never
having to discuss these choices again.

Adopting black has helped in all projects I (help) maintain. A few of them
are well known, but the specific projects do not matter much.

And I'm one of those people who hesitated because I didn't like many of the
choices black made but I adapted really quickly.

Thanks,
Matthias

On Sat, Apr 13, 2019 at 5:35 PM Herman S  wrote:

> Hi.
>
> I propose that Django starts using 'black' [0] to auto-format all Python
> code.
> For those unfamiliar with 'black' I recommend reading the the projects
> README.
> The short version: it aims to reduce bike-shedding and non value-adding
> discussions; saving time reviewing code; and making the barrier to entry
> lower
> by taking some uncompromissing choices with regards to formatting.  This is
> similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.
>
> Personally I first got involved contributing to Django couple of weeks
> back,
> and from anecdotal experience I can testify to how 'formatting of code'
> creates
> a huge barrier for entry. My PR at the time went multiple times back and
> forth
> tweaking formatting. Before this, I had to research the style used by
> exploring
> the docs at length and reading at least 10-20 different source – and even
> those
> were not always consistent. At the end of the day I felt like almost 50%
> of the
> time I used on the patch was not used on actually solving the issue at
> hand.
> Thinking about code formatting in 2019 is a mental energy better used for
> other
> things, and it feels unnecessary that core developers on Django spend
> their time
> "nit-picking" on these things.
>
> I recently led the efforts to make this change where I work. We have a
> 200K+
> LOC Django code-base with more than 30K commits. Some key take-aways: it
> has
> drastically changed the way we work with code across teams, new engineers
> are
> easier on-boarded, PR are more focused on architectural choices and "naming
> things", existing PRs before migration had surprisingly few conflicts and
> were
> easy to fix, hot code paths are already "blameable" and it's easy to blame
> a
> line of code and go past the "black-commit", and lastly the migration went
> without any issues or down-time.
>
> I had some really fruitful discussions at DjangoCon Europe this week on
> this
> very topic, and it seems we are not alone in these experiences. I would
> love to
> hear from all of you and hope that we can land on something that will
> enable
> *more* people to easier contribute back to this project.
>
> I've set up how this _could_ look depending on some configurables in Black:
>
> * Default config: https://github.com/hermansc/django/pull/1
> * Line length kept at 119: https://github.com/hermansc/django/pull/3
> * Line length kept at 119, no string normalization:
> https://github.com/hermansc/django/pull/2
>
> Please have a look at the Black documentation. It explains the benefits
> better
> than I possibly could do here.
>
> With kind regards,
> Herman Schistad
>
> [0]: https://github.com/ambv/black
>
> --
> 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/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
www.feinheit.ch — berat...@feinheit.ch — +41 555 11 11 41

-- 
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/CANvPqgBua2Jsga7f4jTaaW45%3DcROcxXt1zUbx2wH%2Bs4TJRp7Hg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Force "required" fields to be included in a ModelForm

[Matthias Kestenholz]

 Please don't do this.

There are very good reasons for NOT including blank=False fields by default
such as batch-editing some field with a formset or inlineformset or just
offering different forms to users with different access levels (as Tobias
wrote).

Django started recommending using `fields` instead of `exclude` with good
reasons. Why push people towards `exclude` again now? I think we should
instead trust developers who specify `fields` that those actually are the
fields they want in the form. Using `fields` *is* explicit already.

If it is hard to put this behavior into a base form class in your own
project and use this base class everywhere then that would be a good reason
to consider changing a thing or two in Django.

Thanks,
m.

On Wed, Apr 17, 2019 at 3:14 AM Will Gordon  wrote:

> Would it be weird to just make it so that the "required" field *must* be
> present in exclude? This way, if you *accidentally* leave off a required
> field, you're quickly notified about itbut if you explicitly mark it as
> something to exclude, it makes it clear to everyone exactly what you're
> trying to do? The whole "explicit is better than implicit" and what not.
>
> --
> 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/c0b7e5d5-f422-42be-ace8-c0201a2f79a7%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
www.feinheit.ch — berat...@feinheit.ch — +41 555 11 11 41

-- 
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/CANvPqgDoTQoh1WDzNXaj1Ob%2BOV-pG8CxugQhwumuZQ_VQLPnzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: translation.E005 / Should LANGUAGES_BIDI be a strict subset of LANGUAGES?

[Matthias Kestenholz]

Checking that entries in LANGUAGES and LANGUAGES_BIDI are well formed
certainly makes sense! I wouldn't want to back out this part of the change.

All settings come with a certain risk of inconsistencies or with unexpected
behavior.

That being said, this particular change just seems so patronizing. As a
team we have launched literally hundreds of projects based on Django (some
of them using RTL languages) and released dozens of Django libraries and
have never had a problem related to LANGUAGES_BIDI. And now, just because
there's a possibility of an inconsistency I'll have to add the same line to
each project when the whole thing can be avoided in the first place by
keeping the meaning of LANGUAGES and LANGUAGES_BIDI orthogonal and just not
introducing this dependency.

Matthias


On Tue, Apr 9, 2019 at 2:19 PM Tobias McNulty 
wrote:

> Having thought about this a little more, I may have found in answer to my
> own question. :-)
>
> The reasoning would seem to be that, by overriding LANGUAGES but not
> LANGUAGES_BIDI, you risk introducing an inconsistency between the language
> code *format* in these two settings (a la LANGUAGE_CODE and the original
> ticket that got this started). If that's correct, that seems fair to me
> (and worth keeping this check), along with an update to the docs to clarify
> this dependency and why it exists.
>
> Tobias
>
> On Tue, Apr 9, 2019, 8:06 AM Adam Johnson  wrote:
>
>> Other ideas:
>>
>>- Bypass the check in the case that LANGAUGES_BIDI is the same as the
>>one in global_settings - probably not the best idea, but would stop all
>>projects having to set LANGUAGES_BIDI = [] to avoid the check
>>- Change startproject so that LANGUAGES_BIDI is set up as the empty
>>list - removes some "included batteries" but helps users make a more
>>informed choice?
>>
>>
>> On Tue, 9 Apr 2019 at 12:27, Adam Johnson  wrote:
>>
>>> Hi Matthias,
>>>
>>> I can see why this is annoying. At least the resolution is easy by
>>> setting LANGUAGES_BIDI = []. I do agree that it should be in the release
>>> notes, although it's quite hard to miss a new system check's output when
>>> upgrading.
>>>
>>> I see it was only at the last review of the PR (
>>> https://github.com/django/django/pull/11060 ) that the check in
>>> question was upgraded from warning W005 to E005. I can see why a warning
>>> would make sense, but at the same time a warning is still a message to the
>>> user and resolved the same way, either by setting LANGUAGES_BIDI or adding
>>> it to SILENCED_SYSTEM_CHECKS.
>>>
>>> I think I'm against removing the check, but pro anything that can make
>>> it easier for users such as yourself - perhaps something as simple as a
>>> suggestion in the error message to set LANGUAGES_BIDI = [] if you're not
>>> using RTL languages?
>>>
>>> Thanks,
>>>
>>> Adam
>>>
>>> On Tue, 9 Apr 2019 at 11:22, Matthias Kestenholz  wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> The resolution of https://code.djangoproject.com/ticket/30241 in
>>>> https://github.com/django/django/commit/4400d8296d268f5a8523cd02ddc33b12219b2535
>>>> introduced a new and in my opinion backwards incompatible requirement
>>>> through the system checks framework.
>>>>
>>>> Previously*, overriding LANGUAGES to restrict the list of available
>>>> languages on a Django site worked. Now it's also necessary to override
>>>> LANGUAGES_BIDI because there is a new system check (translation.E005) which
>>>> verifies that there are no language codes in LANGUAGES_BIDI not in
>>>> LANGUAGES as well.
>>>>
>>>> It is my strong opinion that enforcing this does not provide any
>>>> benefits and has the downside of forcing almost everyone who overrides
>>>> LANGUAGES to now add a new setting to their project to override
>>>> LANGUAGES_BIDI as well with unclear benefits.
>>>>
>>>> Strictness is a good thing, but since LANGUAGES_BIDI is only ever used
>>>> for membership checking (and never iterated over) I don't see the problem
>>>> in keeping the default language codes from django/conf/global_settings.py
>>>> in there even though some of those languages may not be available on a
>>>> given installation anyway.
>>>>
>>>> The report in https://code.djangoproject.com/ticket/30342 was closed
>>>> as wontfix that's why I'm writing to the list. Also, since system checks
>>>> gen

Re: translation.E005 / Should LANGUAGES_BIDI be a strict subset of LANGUAGES?

[Matthias Kestenholz]

Hi Adam

Thanks for your answer. I'll try to convince you (and others) that the
error in question does not make sense, not even when downgraded to a
warning.

There are system checks which provide great value such as
django.contrib.admin checking whether templates, context processors etc.
are configured correctly because it would be very confusing if the admin
interface would not show messages after all.

There are other checks such as this one which do not protect the code from
going wrong but that simply impose additional requirements to Django users.

I've reread the discussion in the pull request and haven't found a single
reason why it is a good thing to start requiring that LANGUAGES_BIDI is
specified explicitly. What is the rationale for requiring an explicit
LANGUAGES_BIDI when all you want to do is restrict the overall list of
languages for a single project (or the testsuite of many Django libraries
for that matter)?

After all, the set of bidirectional languages does not change just because
some of them aren't active inside a given project. And there is no
ambiguity when inheriting LANGUAGES_BIDI from django.conf.global_settings
and only overriding LANGUAGES.

Thanks,
Matthias

On Tue, Apr 9, 2019 at 1:28 PM Adam Johnson  wrote:

> Hi Matthias,
>
> I can see why this is annoying. At least the resolution is easy by setting
> LANGUAGES_BIDI = []. I do agree that it should be in the release notes,
> although it's quite hard to miss a new system check's output when upgrading.
>
> I see it was only at the last review of the PR (
> https://github.com/django/django/pull/11060 ) that the check in question
> was upgraded from warning W005 to E005. I can see why a warning would make
> sense, but at the same time a warning is still a message to the user and
> resolved the same way, either by setting LANGUAGES_BIDI or adding it to
> SILENCED_SYSTEM_CHECKS.
>
> I think I'm against removing the check, but pro anything that can make it
> easier for users such as yourself - perhaps something as simple as a
> suggestion in the error message to set LANGUAGES_BIDI = [] if you're not
> using RTL languages?
>
> Thanks,
>
> Adam
>
> On Tue, 9 Apr 2019 at 11:22, Matthias Kestenholz  wrote:
>
>> Hello everyone,
>>
>> The resolution of https://code.djangoproject.com/ticket/30241 in
>> https://github.com/django/django/commit/4400d8296d268f5a8523cd02ddc33b12219b2535
>> introduced a new and in my opinion backwards incompatible requirement
>> through the system checks framework.
>>
>> Previously*, overriding LANGUAGES to restrict the list of available
>> languages on a Django site worked. Now it's also necessary to override
>> LANGUAGES_BIDI because there is a new system check (translation.E005) which
>> verifies that there are no language codes in LANGUAGES_BIDI not in
>> LANGUAGES as well.
>>
>> It is my strong opinion that enforcing this does not provide any benefits
>> and has the downside of forcing almost everyone who overrides LANGUAGES to
>> now add a new setting to their project to override LANGUAGES_BIDI as well
>> with unclear benefits.
>>
>> Strictness is a good thing, but since LANGUAGES_BIDI is only ever used
>> for membership checking (and never iterated over) I don't see the problem
>> in keeping the default language codes from django/conf/global_settings.py
>> in there even though some of those languages may not be available on a
>> given installation anyway.
>>
>> The report in https://code.djangoproject.com/ticket/30342 was closed as
>> wontfix that's why I'm writing to the list. Also, since system checks
>> generally aren't mentioned in the release notes users will not be informed
>> ahead of time about this change when reading the release notes.
>>
>> Anyone has any opinions to offer on this?
>>
>> Thanks,
>> Matthias
>>
>> * At least as long as I'm using Django, probably for 11 years or
>> something.
>>
>> --
>> 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/CANvPqgAy_HytsvmnOpPtrCP_969QhoncJaPUe%3D6pN-VYWMVcjA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CANvPqgAy_HytsvmnOpPtrCP_969QhoncJaPUe%3D6pN-VYWMVcjA%40mail.gmail.com?utm_medium

translation.E005 / Should LANGUAGES_BIDI be a strict subset of LANGUAGES?

[Matthias Kestenholz]

Hello everyone,

The resolution of https://code.djangoproject.com/ticket/30241 in
https://github.com/django/django/commit/4400d8296d268f5a8523cd02ddc33b12219b2535
introduced a new and in my opinion backwards incompatible requirement
through the system checks framework.

Previously*, overriding LANGUAGES to restrict the list of available
languages on a Django site worked. Now it's also necessary to override
LANGUAGES_BIDI because there is a new system check (translation.E005) which
verifies that there are no language codes in LANGUAGES_BIDI not in
LANGUAGES as well.

It is my strong opinion that enforcing this does not provide any benefits
and has the downside of forcing almost everyone who overrides LANGUAGES to
now add a new setting to their project to override LANGUAGES_BIDI as well
with unclear benefits.

Strictness is a good thing, but since LANGUAGES_BIDI is only ever used for
membership checking (and never iterated over) I don't see the problem in
keeping the default language codes from django/conf/global_settings.py in
there even though some of those languages may not be available on a given
installation anyway.

The report in https://code.djangoproject.com/ticket/30342 was closed as
wontfix that's why I'm writing to the list. Also, since system checks
generally aren't mentioned in the release notes users will not be informed
ahead of time about this change when reading the release notes.

Anyone has any opinions to offer on this?

Thanks,
Matthias

* At least as long as I'm using Django, probably for 11 years or something.

-- 
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/CANvPqgAy_HytsvmnOpPtrCP_969QhoncJaPUe%3D6pN-VYWMVcjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Enable SESSION_COOKIE_SECURE by Default

[Matthias Kestenholz]

On Wed, Apr 3, 2019 at 11:39 AM James Bennett  wrote:

> On Wed, Apr 3, 2019 at 2:34 AM Carlton Gibson 
> wrote:
>
>> Yes, super thanks. Breaking login in development would qualify as a good
>> *Why* yes. 
>>
>> I'll assume we're NOT going to do this, but anyone with input, please do
>> comment.
>>
>
> Historically I've done something along the lines of
>
> CSRF_COOKIE_SECURE = not DEBUG
> SESSION_COOKIE_SECURE = not DEBUG
>
> That guarantees I never go to production without the cookies set to
> secure, but also avoids breaking local dev. I do similar things with other
> SSL-related settings.
>
> I'm not sure how well it generalizes to other people's use cases, though.
>

I do this too, but not using "not DEBUG" but SECURE_SSL_REDIRECT (or the
related setting for django-canonical-domain). It might be a good idea to
add something like this to the project template?

-- 
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/CANvPqgCES-_-%3D8V%2BuAxecqC-Xd2sUaqeDRiSeX%2Byz0OXrfZRUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Enable SESSION_COOKIE_SECURE by Default

[Matthias Kestenholz]

On Wed, Apr 3, 2019 at 10:02 AM Carlton Gibson 
wrote:

> Hi all.
>
> https://code.djangoproject.com/ticket/30314
>
> >  Per the documentation, "Leaving this setting off isn’t a good idea
> because an attacker could capture an unencrypted session cookie with a
> packet sniffer and use the cookie to hijack the user’s session."
> >
> > If it's not a good idea for this setting to be off, why is it off by
> default? Seems backwards to me.
>
> This looks right to me. A small breaking change for 3.0 would seem
> reasonable. So I'm going to Accept this.
>
> BUT this has been this way forever
> 
>  so
> I just wanted to check if there were any overriding *Whys*?
>

(The same reasoning should probably be applied to CSRF_COOKIE_SECURE.)

My opinion is that this isn't a good idea. Right now it's possible to
always have the SecurityMiddleware in MIDDLEWARE without adding any
security-specific settings to the default setup. You get the following
benefits:

- Authenticating when developing locally works (as I understand it it does
not with *_COOKIE_SECURE set to True because you can't authenticate anymore
on the http: development server)
- You get the SecurityMiddleware's warnings if you do not enable those
settings when DEBUG=False

I fear that more people will remove the SecurityMiddleware (which is in the
default setup) instead of deactivating secure cookies for local development
which means a net negative for security.

Thanks,
Matthias

-- 
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/CANvPqgCBK4B5k4hFPnvQvHv4ie2Bd0gnbw1sNhdCFb5KC7jsSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding generated common table expressions

[Matthias Kestenholz]

Hi,

On Sat, Mar 18, 2017 at 12:49 AM, Tim Graham  wrote:
> Hi, I don't know anything about CTE, but did you see this third-party
> package? https://github.com/petrounias/django-cte-trees -- It seems to be
> PostgreSQL only.

Just chiming in to point out a maintained and up-to-date friendly fork
of the project above:
https://github.com/matthiask/django-cte-forest

Ashley, is your PoC available somewhere? Is your implementation in any
way similar to the implementation in
django-cte-trees/django-cte-forest?

Thanks,
Matthias

-- 
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/CANvPqgDWUPuUA6rw8uawa7_AsUkXFhuegFM1cJ-gjVUCxvBUwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form.Media: render inline css/js

[Matthias Kestenholz]

On Thursday, September 29, 2016 at 4:11:04 PM UTC+2, is_null wrote:
>
> Thanks for the heads up, a similar ticket has been closed as wontfix, 
> because it isn't compatible with CSP: 
> https://code.djangoproject.com/ticket/13978
>
> While I'm all against inline scripts, I have a use case which seems be 
> legitimate: 
> https://github.com/yourlabs/django-autocomplete-light/pull/733/files#diff-469b501dd1f427cfe68aac4d27f28df3R84
>
> Basically, we render a `json object 
> dump here` next to the widget and use that to configure the script 
> for that widget. IMHO, the ideal solution would be to be able to place this 
> script tag in `{{ form.media }}` rather than next to the HTML widget.
>
>
There is precedent in Django (respectively django.contrib.admin) for adding 
attributes to the script tag, for example here:
https://github.com/django/django/blob/master/django/contrib/admin/templates/admin/popup_response.html

I have an admittedly ugly hack here which allows (ab)using forms.Media for 
custom additional attributes here: (It works well and I sleep well, but 
it's not nice at all.)
https://github.com/matthiask/django-content-editor/blob/master/content_editor/admin.py#L93

If this is an acceptable way of delivering additional data to the frontend 
code I might work on that during a sprint some time?

Thanks,
Matthias


-- 
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/2782925a-0d2f-44d9-a055-36b3cc4a1078%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ModelView

[Matthias Kestenholz]

On Mon, Jul 12, 2010 at 2:13 PM, Roald  wrote:
> Hi all,
>
>
> There is a discussion 'Class based generic views in 1.3?' in this
> list. I would like to suggest an alternative: ModelViews. There
> normally are multiple standard views associated with one model, and
> such a class can take advantage of that. Its use should look something
> like this:
>
>
>    []
>
> Anybody likes the idea? There are a few remarks I'd already like to
> make:
> - I'm not sure 'ModelView' is the right name for this, since not the
> class itself but its requesthandler properties are the actual views.
> On the other hand, the name is too nice not to be used.
> - I'm no fan of 'class Meta' myself, but I've chosen it here to be
> compatible with ModelForm
>

I sort-of like this, but don't see why anything like this should land
in Django core, because it doesn't improve the generic view usecase in
any significant manner IMHO.

There exist several implementations of this idea:

http://github.com/matthiask/modelviews (my own)
http://code.welldev.org/django-modelviews/wiki/Home

... and there might well be others which I am not aware of.


Putting request specific variables on the view instance like you
propose it is still a bad idea though. It leads to cross-pollination
of different request handling stages and unclean separation of
concerns.

Oh well, that was a reply to "the other thread"...




Matthias



-- 
Django CMS building toolkit: http://www.feinheit.ch/labs/feincms-django-cms/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: I want a pony: Distributed RCS

[Matthias Kestenholz]

On Thu, Sep 11, 2008 at 10:40 AM, Matthias Kestenholz <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 11, 2008 at 10:17 AM, Michael Radziej <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> On Wed, Sep 10, Malcolm Tredinnick wrote:
>>> Commit ids are stable in, for example, git-svn,
>>> so merges will be the same for everybody who merges from a
>>> subversion-tracking branch to their development branch (in the sense
>>> that everybody pulling from subversion will get the same commit id for
>>> the same upstream commit; it just won't necessarily match the one they
>>> were using on their development branch if it wasn't pulled from
>>> subversion.
>>
>> I've also used git for some time now to track Django. I happen to use
>> git-svnimport, since I don't commit. It's not very hard to sync with
>> subversion, but one thing is annonying: Your commits depend on whether you
>> use git-svn or (deprecated) git-svnimport, and on the options you choose.
>> This creates a few superficial annoyances when you want to share a git tree.
>>
>> As a proposal, can we "officially" recommend JKM's git tree is kind of 
>> official and link it
>> prominently?
>
> It does not matter which import we officially recommend, because the SHA-1 ids

I just checked, and the two repositories have diverged. Jacob's
repository contains
a merge commit from 12 days ago[1] which is not recorded as a merge in the
subversion history and does not appear as a merge in all other git-svn imports.

I'm not sure at all if it matters though, since Django development happens with
patches that are posted to trac.

[1]: 
<http://code.djangoproject.com/git/?p=django;a=commit;h=c894f853a2c5b59d86ba854a2beae34129047ef5>
, 'Merge branch 'url-tag-asvar'

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: I want a pony: Distributed RCS

[Matthias Kestenholz]

On Thu, Sep 11, 2008 at 10:17 AM, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> On Wed, Sep 10, Malcolm Tredinnick wrote:
>> Commit ids are stable in, for example, git-svn,
>> so merges will be the same for everybody who merges from a
>> subversion-tracking branch to their development branch (in the sense
>> that everybody pulling from subversion will get the same commit id for
>> the same upstream commit; it just won't necessarily match the one they
>> were using on their development branch if it wasn't pulled from
>> subversion.
>
> I've also used git for some time now to track Django. I happen to use
> git-svnimport, since I don't commit. It's not very hard to sync with
> subversion, but one thing is annonying: Your commits depend on whether you
> use git-svn or (deprecated) git-svnimport, and on the options you choose.
> This creates a few superficial annoyances when you want to share a git tree.
>
> As a proposal, can we "officially" recommend JKM's git tree is kind of 
> official and link it
> prominently?

It does not matter which import we officially recommend, because the SHA-1 ids
are the same for every git-svn import as long as you use the same SVN base URL.
You should not use git-svnimport anymore, git-svn is more feature complete and
is more actively developed.

Several git and hg repositories are listed here:
http://code.djangoproject.com/wiki/DjangoBranches

Mine is updated hourly and since I rely on the service myself it will
surely stay for
some time.


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: multi-delete and edit form+changelist unification

[Matthias Kestenholz]

On Mon, Sep 8, 2008 at 6:55 PM, Ben Firshman <[EMAIL PROTECTED]> wrote:
>
>
> On 8 Sep 2008, at 13:36, Erik Allik wrote:
>
>>
>> I'm glad this came up, because I would also like to recommend
>> considering an admin interface for models that use django-mptt. I know
>> django-mptt is an external project but I think many people are using
>> django-mptt as it's currently the most popular tree solution available
>> for Django.
>>
>> What do people think?
>
> tusk-cms [0] has a fantastic admin interface for django-mptt based
> around the jQuery nestedSortables widget [1]. I adapted it for use on
> one of my own projects, and it wasn't too hard. If there's interest,
> I'll write a patch for django-mptt for a generic admin interface.
>

Please do that! Unfortunately I don't have any time currently to clean up
the code and submit it for inclusion but if it gets you started that's great.

Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[Matthias Kestenholz]

On Mon, 2008-06-09 at 21:16 -0400, Karen Tracey wrote:
> On Sat, Jun 7, 2008 at 3:06 PM, Jacob Kaplan-Moss
> <[EMAIL PROTECTED]> wrote:
> * Start a "train release" schedule: schedule a couple of 1.0
> betas, a
> rc or two, and then a final release. Features that are done by
> the
> dates get released, those that aren't, don't. Make these dates
> aggressive but not crazy. And -- here's the controversial part
> -- make
> newforms-admin an "optional" part. If it's done, awesome; if
> not,
> include it in the next release. The current admin has some
> bugs, yes,
> but it's usable enough. As long as we advertised that it's on
> the way
> out we shouldn't have too much trouble.
> 
> Thoughts?
> 
> I'd trade your controversial part for an alternative: merge
> mewforms-admin back to trunk now.  It's been as 'usable' as old admin
> for months.  Sure, it's got a couple of dozen 'blocking' bugs in the
> tracker but none of them are all that serious.  Current admin, as you
> note, also has some bugs.  Trade the existing
> known-never-going-to-be-fixed current admin bugs for a different set
> of newforms-admin bugs and get on with fixing the second set already.
> Once on trunk the community's interest will be higher so you'll get
> better feedback on what is and is not really important to users, more
> people who might help out with actual fixes, etc.  

+1

I know there is a commitment to keep trunk as stable as possible, but if
there is a push for moving forward quickly, this is the way to go. I'm
running newforms-admin for several public sites already, and have not
experienced a single problem which I'd remember now. Porting from the
current admin to nfa was very straightforward too.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: [GSoC] Aggregate Support to the ORM

[Matthias Kestenholz]

Hi.

this is very exciting! I've one suggestion/question though.

On Tue, 2008-04-22 at 13:24 -0700, Nicolas E. Lara G. wrote:
> with the possibility of using non-keyword arguments for un-aliased
> aggregation, in which case the 'alias' would be automatically created
> from the query made:
>  >>> Students.objects.all().aggregate('height__avg')
> {'height_avg' : 1.43}
> 

Was the name-munging here done intentionally? I think, that it's a bad
choice to leave one of the underlines out. I think that it's too easy to
shoot oneself in the foot with such magic (Think denormalized table
schemas).

Apart from that: Great stuff, can't wait for it :-)


Matthias

-- 
http://spinlock.ch/blog/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---