Re: Proposal to add a flatten() to django.utils

Hi David, I think, I'm in support for a django.utilsflatten() function with the requirements / constraints you outlined below. Cheers, Markus On Mon, Oct 17, 2022, at 8:31 AM, David Sanders wrote: > Hi folks, > > As part of PR 16175 there was

Re: Preparing Django code for the Black stable release

That's wonderful news. Thanks for the info, Paolo! Cheers, Markus On Sat, Jan 29, 2022, at 10:24 PM, Paolo Melchiorre wrote: > Hi all, > > Black 22.1.0 has just been released > https://github.com/psf/black/releases/tag/22.1.0 > > It seems the time has come to put DEP 0008 into practice and "run

Re: Preparing Django code for the Black stable release

There is https://github.com/MarkusH/django-migrations-formatter which I think holds everything that's necessary to make the migration writer create black-formatted output. Cheers, Markus On Wed, Oct 20, 2021, at 11:11 AM, 'Adam Johnson' via Django developers (Contributions to Django itself)

Re: Proposal for a transaction.on_before_commit

Hi Raphael, This is funny. Just last week I looked into exactly the same thing for audit logging as well. Except that I'm writing multiple audit log events and want to batch them at the end of the transaction in a single bulk_create operation instead of a dozen save() calls. I haven't gotten

Re: RSS access to Google groups?

Hi Claude, I think you're receiving everything because you're a moderator everywhere and they get everything they're moderating by default. I'd need to look into this a bit more. But I think there's a way to disable excess notifications. Cheers, Markus On Fri, Aug 13, 2021, at 10:53 PM,

Re: The certificate for code.djangoproject.com expired on 7/4/2021.

We had some intermittent connection issues over the last couple of hours: https://status.djangoproject.com/. All should be fine again. Cheers On Sun, Jul 4, 2021, at 4:14 PM, chris.j...@gmail.com wrote: > Maybe someone can file an issue about it to address the same thing > happening in the

Re: Default change password UX: area for improvements

Hi Federico, this is a good idea. Could you check if there's a ticket about this on https://code.djangoproject.com/ already, and if not, possibly open one. That would be much appreciated. Thank you! Cheers, Markus On Mon, Jun 7, 2021, at 11:12 PM, Federico Capoano wrote: > Hey everyone, > >

Re: Proposal to add attribute 'step' to FloatField and DecimalField

Hi Jacob, That sounds like a sensible feature. Do you want to open a ticket and maybe implement it? Cheers Markus On Wed, Mar 17, 2021, at 12:45 AM, Jacob Rief wrote: > If someone wants to use the step attribute as provided by the HTML field > , she/he has to specify that using for instance

Re: The blacklist / master issue

Hi all, Mariusz renamed the branches this morning and merged the corresponding pull requests. Thank you! Please let us know if you spot problems so they can be fixed. Cheers, Markus On Tue, Mar 2, 2021, at 6:05 PM, Markus Holtermann wrote: > Brief update on this. > > The overall

Re: The blacklist / master issue

, 2021, at 7:31 PM, Markus Holtermann wrote: > Thanks for the input, Matthias. That's useful to know. I'll make sure > the change is announced. > > Cheers, > > Markus > > On Thu, Feb 25, 2021, at 7:24 PM, Matthias Kestenholz wrote: > > Yes, please. > > >

Re: The blacklist / master issue

ll need some find/replace for > > links in the main repo, on djangoproject.com <http://djangoproject.com>, > > and I imagine some other places. > > > > On Tue, 23 Feb 2021 at 22:15, Kenneth > <mailto:kennethl...@gmail.com>> wrote: > > > >

Re: The blacklist / master issue

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.

Re: Revisiting Python support for after Django 3.2 LTS

I think I need to go through all proposed options a few more times to understand their differences and implications. But what about a more pragmatic approach: Django supports the currently supported Python versions at any given time. Except for our LTS versions, which would never drop support.

Re: Technical Board Decision Needed: Admin append_slash behaviour.

Thanks you for bringing this up, Carlton. And thanks Jon for tackling the issues. I concur with what has been said so far. Especially what James said, that there are so many places where one possibly/maybe/theoretically could come up with timing attacks. Mitigating the difference in response

Re: Anonymous access to the forum

Thanks Adam. I did set the value to "Anyone on the web" again (it had that value already). And since that didn't change anything I went public: https://twitter.com/m_holtermann/status/1295635386820157440 What _does_ work, is viewing threads directly, only showing a list of threads doesn't work

Re: Anonymous access to the forum

Thanks for bringing this up, Claude. I'll look into it. Cheers, Markus On Tue, Aug 18, 2020, at 9:14 AM, Claude Paroz wrote: > Hello, > > Am I the only one or did Google closed anonymous access to Google groups? > Could it be a setting in the group config? > > In my opinion, it is not

Re: Set up autolinks on Django's GitHub repositories

Hi Sage, thank you for the suggestion. There's already autolinking setup for `ticket-123`. I'm happy to add another one which would be a bit briefer. But if this is done, the contribution documentation needs to be updated as well. /Markus On Mon, Aug 3, 2020, at 8:06 AM, laym...@gmail.com

Re: Status of 3.1 release blockers.

Can we come up with a way that we have the settings variable around for now, only to allow transitioning, and then add it as a proper feature in 3.2. As for the feature, I think we could choose a path like passlib does: A list of 2 (n>=1) algorithms. The first one will be used for signing, and

Re: Status of 3.1 release blockers.

No, it won't move the problem to 3.2. The problem is that 3.0 only knows about sha1. 3.1 and later know about sha1 and sha256. Meaning, any >=3.1,<4.0 version can decode and verify signed data from 4.0 and before. Cheers Markus On Fri, Jul 31, 2020, at 12:08 PM, Raffaele Salmaso wrote: > On

Re: Status of 3.1 release blockers.

Thank you for summarizing our IRC discussion, Mariusz. To be clear, the problem occurs during the upgrade process where more than 1 server is involved. That might be the case in small deployments with just 2 servers, where the time of two Django versions running simultaneously is likely small,

Re: f-strings again.

I've been one of those who previously were against adding them to Django. Mostly, because I wasn't used to them and didn't see their value. But more importantly, because I was worried about unintended security issues they could cause. Why the latter is still present, I've think the

Re: The blacklist / master issue

First things first: I'm glad, Django changed master/slave and blacklist/whitelist to more appropriate and adequate terms. Naming things is hard. And just because somebody came up with a name decades ago doesn't mean it can't — or even shouldn't — be changed. Especially when there are more

Re: The blacklist / master issue

I'd be in favor of changing blacklist/whitelist into something that makes sense. In many cases, that's going to be context dependent, but often blocklist/allowlist will work. With regards to "master" as the development branch on GitHub, I'd like to pick whatever GitHub eventually goes with as

Re: Unsolicited mentorship requests

Interesting. Because I got a similar messages this morning, one on Twitter and one on LinkedIn. Here's my response: > Hi {{ name }}. Thank you for reaching out. Unfortunately, I'm not available > for outside help at this time. If you need help working on Django projects > would like to suggest

Re: What happens if a Fellow has a holiday?

Enjoy your time off. I'll keep my eyes open for PRs. Cheers, Markus On Thu, Jun 4, 2020, at 2:09 PM, charettes wrote: > Happy to review help as well. > > Enjoy your well deserved time off! > > Le jeudi 4 juin 2020 06:47:57 UTC-4, Carlton Gibson a écrit : > > Hi all. > > > > Short answer is

Re: Clear all filters

I tend to agree with Adam. >From a UI/UX perspective, the location where the "Clear all filters" button >is, as well as the wording, suggest to me that it's only the filters on the >right side. The search query, while technically filtering the query set, >doesn't seem like a filter in the UI.

Re: Django Version 3.2 Roadmap

Hi Carlton, thank you. The proposal looks good to me. +1 Cheers, Markus On Wed, May 13, 2020, at 2:51 PM, Carlton Gibson wrote: > Hi all. > > I've prepared a draft of the Roadmap for Django 3.2 here: > > https://code.djangoproject.com/wiki/Version3.2Roadmap > > Following the established

Re: Ticket #25236: Remove ifequal from the template language

Yes please! Nice catch and followup :) Cheers, Markus On Mon, May 4, 2020, at 4:08 PM, Jon Dufresne wrote: > Hi, > > I'd like to raise this topic for renewed discussion. I think it is time > to begin deprecating the obsolete template tags. So +1 for removal. > > I had all but forgotten about

Re: [FEATURE] Allow squashmigrations to squash the whole project

But for isort one specifies the `known_first_party` and `known_third_party` packages. https://github.com/timothycrosley/isort#configuring-isort At least I was under the impression that that's the only way how it decides where to place imports. Cheers, Markus On Tue, Apr 28, 2020, at 9:41 PM,

Re: [FEATURE] Allow squashmigrations to squash the whole project

Have you considered to allow for multiple app_labels in the `squashmigrations` command, maybe together with a `--cross-app` flag, to specify the apps from which migrations should be squashed? That way we don't need to rely on paths at all, but can log up all migrations in question, based on the

Re: Generate JWTs with Django

Nice work, Claude! However, dealing with JWTs, and especially verifying them is notoriously hard and fragile. Frankly, I think I'd rather see smaller libraries do one job and do it well, than having Django implement an incomplete JWT spec. As far as I can tell, only HS256 signing/verification

Re: Progress report: DEP 10 implementation

Thanks for the summary, James. As one of the IRC group contacts, here's the proposal for what happens to the cloaks on Freenode: - Right now there's a @django/committer/$name cloak. We'd abandon that cloak. - Instead, every DSF member can apply for a @django/member/$name cloak by getting in

Re: New Merger nomination.

I vote in favor of Claude becoming a MERGER. Cheers, Markus On Thu, Apr 16, 2020, at 10:31 PM, charettes wrote: > I cast my vote in favor of Claude's nomination as well. > > Le jeudi 16 avril 2020 16:16:31 UTC-4, Adam Johnson a écrit : > > This has fallen by the wayside, let's try restarting.

Re: Technical Board statement on type hints for Django

Thanks for pushing this public, Adam. In the discussion I brought up these points. I've been using static typing in Python for about 1.5 years now. Every now and then it's neat, but often enough I get annoyed by it. Either because I simply don't know how to use the tools at hand correctly or

Re: Proposal to deprecate NullBooleanField (and remove in Django 4.0)

Makes sense. We'd have the deprecation shims around for a while anyway. /Markus On Tue, Mar 17, 2020, at 11:10 AM, Carlton Gibson wrote: > Ok, that’s pretty quick and conclusive, so let’s progress. Thanks all. > > On Tue, 17 Mar 2020 at 11:00, Shrawan Poudel wrote: > > +1 from me > > > > On

Re: New Merger nomination.

Thanks James for summarizing the process. Thanks Mariusz for the suggestion. Let's make it official, then. I'd like to nominate Claude Paroz (https://github.com/claudep) to be a Merger for the Django project and ask my fellow Technical Board members to cast their votes. Claude has been

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

Thanks for checking and asking! On Python 2, the email address with "i without dot" isn't a valid email address according to the EmailValidator and thus shouldn't be in your database in the first place. Cheers, /Markus On Wed, Dec 18, 2019, at 11:23 AM, Sam Willis wrote: > Hi, > > It looks

Re: Django 3.0 Release Notes - ASGI

Good point, Josh. I think we should either add an "experimental" note to the ASGI notes or introduce an "Experimental changes" section (I'm open to other naming suggestions) /Markus On Tue, Oct 15, 2019, at 9:45 AM, Josh Smeaton wrote: > A co-worker just linked me to >

Re: Add Optional Slash Syntax for Path

Hi Jason, Great catch, but I think I agree with Carlton on this one for the reason he mentioned, but even more so for what you already pointed out: "it is better design to not allow for two lvalid endpoints for the same path". Cheers Markus On Thu, Aug 29, 2019, at 7:15 AM, Carlton Gibson

Re: Proposing development discussion forums

Thank you for bringing up the idea, Andrew. As expressed at PyCon AU, I'd be interested in giving an alternative to a mailing list a shot. Something that supports subscribing to topics sounds like a good idea to overcome the amount of mails one may not be interested in. Cheers, Markus On

Re: Migrations: A bug or a feature needing documentation?

Hi Barry, TL;DR: I think this is a bug and can lead to inconsistencies in other project setups than yours. Let's look at the last question first, regarding duplicate entries in the django_migrations table: Yes, this is to be a bug. At least how it's currently used. Let's say you have

Re: Translation templatetag aliases

Easy: +1 from me as well for reasons state before. /Markus On Sat, Jul 27, 2019, at 6:15 PM, Adam Johnson wrote: > +1 from me too for the reasons that Aymeric states. > > Another small pro: "translate" is a few more characters to type, but it > should make it easier to understand the purpose

Re: Resource loading (Django without a filesystem)

Hi Peter, PyOxidizer looks indeed super interesting. Talking about templates and specifically Jinja2 templates, they are internally converted to the Python AST if I'm not mistaking. Turning them into Python modules that a new Jinja2ModuleTemplateLoader could load doesn't seem like that far

Re: Redis cache support in core

Hi all, may I suggest that django-redis may be "promoted" to an official Django package under the Django GitHub organization? This would follow https://github.com/django/deps/blob/master/final/0007-official-projects.rst . The package would be pointed out explicitly in the Django docs but would

Re: Faster Migrations! But at what cost?

a major undertaking? Or would it be an acceptable cost to pay > > for some performance improvements? > > Given the large adoption of migrations and the fact the Operation API > is publicly documented[2] I would say the performance benefits would > need to be quite substantial to br

Re: Proposal to format Django using black

The primary author of Black, Łukasz Langa, just announced that Black was moved under the PSF umbrella: https://twitter.com/llanga/status/1123980466292445190 I updated the link in the DEP-8 accordingly to https://github.com/python/black/ /Markus On Wed, May 1, 2019, at 2:32 AM, Andrew Godwin

Re: Proposal to format Django using black

 Aymeric. Thank you! On Sun, Apr 28, 2019, at 4:51 PM, Aymeric Augustin wrote: > Hello, > > Here's my attempt at summarizing the conversation in a DEP: > https://github.com/django/deps/pull/55. > > It's easier to read as a rich diff: >

Re: Proposal to format Django using black

 /Markus On Sat, Apr 13, 2019, at 6:08 PM, Florian Apolloner wrote: > As expressed at Djangocon Europe, I am hugely in favor for adopting black. > > If we choose to do this there are a few things to consider: > > * Line-length, we probably want to stay at 119 I guess > * String

Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

Thanks for the proposal, Shai. I quite like it. As discussed at the DCEU sprints I think I'd like to be able to omit the display form of an item and have it auto generated from an item's name, i.e. turning "FOO_BAR" into "Foo Bar" (`key.replace("_", " ").title()`) Further, we could also

Re: De-assigning "Easy pickings" tickets

Hi Carlton, my only question would be why you picked 2 months over 1 or 3. Generally in favor. I think de-assigning somebody after $time of inactivity on a ticket is fair, regardless of the complexity of the ticket. /Markus On Fri, Mar 8, 2019, at 8:30 PM, Carlton Gibson wrote: > Hi all. >

Re: Use CDN for djangoproject.com

Hi all to elaborate on what Tobias said: we deliberately have the infrastructure spread across multiple service providers: DNS registry, nameservers, hosting, TLS certificate authority, … None of them have access to everything. The reason is that we offer the download of the release artifacts

Re: Breaking change vs deprecation on Sitemaps `ping_google` command

tching to https > >> doesn't seem like the sort of change that's going to cause massive pain. > >> > >> On Wednesday, January 9, 2019 at 5:26:37 AM UTC-5, Markus Holtermann > >> wrote:Hi all, > >>> > >>> We could introduce a settings v

Re: Breaking change vs deprecation on Sitemaps `ping_google` command

Hi all, We could introduce a settings variable `SITEMAPS_PING_GOOGLE_HTTPS` that's part of newly created projects' settings (in https://github.com/django/django/blob/master/django/conf/project_template/project_name/settings.py-tpl) and set to `True`. In global_settings.py it defaults to

Re: Add Python 3.7 support for Django 1.11?

Agreed, let's add official 3.7 support. /Markus On Sat, Nov 17, 2018, at 1:15 PM, Adam Johnson wrote: > Since it's about 3 lines in django itself, I think it's a good idea to > backport and save users the pain. > > On Fri, 16 Nov 2018 at 15:37, Ramiro Morales wrote: > > > On Fri, Nov 16, 2018

Standalone is_safe_url() function

Hi all, Django provides a function `django.utils.is_safe_url()` to ensure that a given URL (absolute or relative) is safe to redirect to. I needed that functionality on another project that doesn't use Django at all. I thus built a standalone is-safe-url Python package that can be installed

Re: Adjusting Django's security notification policy

Can: yes. Should: no. I would be really saddened to see companies being able to buy security by throwing money at us. That makes us look like we can be bought. And that sends the wrong signal, from my perspective. Timely security updates should be available to everyone. Should enterprises

Re: [Mixins] - Order of the Mixins - Is it a bug?

Hi Vinnicyus, this is by design. There's an interesting talk by Ana Balica on Mixins in Django: https://www.youtube.com/watch?v=rMn2wC0PuXw /Markus On Fri, Jun 15, 2018 at 02:31:42PM -0300, Vinnicyus Gracindo wrote: Hi. I beat my brains out trying to find out why my cbv was not working with

Re: RFC : Migration Adapters

Hey Curtis, the key of the migration operations ordering is in https://github.com/django/django/blob/d0a42a14c06e033922f6d51e6384cba53be887b6/django/db/migrations/autodetector.py#L159-L195 as you probably have figured out. What _could_ work, it's not more than idea w/o much thinking about it,

Re: GLOBAL_PERMS

Thanks Curtis, I had a quick look. Some thoughts (in no particular order): - IMO a nice idea. I've attached all model independent permissions to the user model in the past to work around the limitation. - How do you envision 3rd party apps handling their own permissions? If I install 2

Re: Provide option to chain QuerySet.order_by()

Thanks for the input, Shai. I'd like to keep the current behavior around. So .order_by(None) would still reset the ordering as-is. But I agree, if we'de exposing QuerySet.query.order_by through a documented API that would work for me as well (in fact, I'm using that right now to work around the

Provide option to chain QuerySet.order_by()

Hi all, I'm in the situation where I'd like to join two .order_by() calls on a QuerySet without losing the ordering set by the first call. This was formerly discussed in https://code.djangoproject.com/ticket/9415 . I agree that simply changing the current behavior is not going to fly due to

Re: Default to BigAutoField

Thanks for taking the effort to work on this, Kenneth! I'm don't fully agree with the approach. This essentially forces 3rd party package authors to make the call about the primary key field size. While for small to medium size projects BigAutoField is unlikely required and only comes with

Re: Problems around SchemaEditor._alter_field

Agreed. As mentioned on IRC, _alter_field() should really be cleaned up. It's also private API and only called from alter_field() I think. And as long alter_field()'s API stays backwards compatible you're pretty much free to do what you need with _alter_field(). /Markus On 05/09/2017 09:23 PM,

Re: Organizing utilities for Django's test suite

Hey Tim, I think we can make a case for including this in django/tests/testcases.py and in a new module tests/utils/something.py which is then only available within Django's own the test suite. I think we should include that test case as part of Django's own test suite for now. It's IMO easier

Re: Some thoughts about improving migration squashing

But if we assert that RemoveField doesn't refer to any models referenced to by its field, then our optimizer can take a couple more liberties. Raphael On Friday, February 17, 2017 at 2:15:47 AM UTC+9, Markus Holtermann wrote: I'm not sure if it's related or not wo what you're investigating, RemoveFi

Re: Some thoughts about improving migration squashing

I'm not sure if it's related or not wo what you're investigating, RemoveField cannot "just" optimized through, as you might have another AddField operation afterwards adding another field with the same name. /Markus On Thu, Feb 16, 2017 at 08:19:01AM -0800, raph...@makeleaps.com wrote: Hey

Re: Some thoughts about improving migration squashing

Thanks Raphael, that's a pretty good write up! You're essentially speaking about 2 things here, in my opinion: 1. Adding a new feature for interactive squash 2. Improving the MigrationOptimizer I certainly see a point for 2. Not sure how much for 1. Anyway, your reasoning for 2 sounds great!

Re: Some thoughts about improving migration squashing

What might be interesting to look into when squashing all migrations in one app would be to assume no migrations would exist. That could then result in only 2 migrations which could run through the optimizer (as opposed to let's say 20 migrations with many more operations). /Markus On

Migrating to new Servers / Trac downtime

Hi y'all, We'll be migrating parts of our infrastructure to new servers. This comes with a short (read-only) downtime of Trac, our issue tracker. We expect the documentation and website to remain online. We'll update here when the migration is done. Cheers, /Markus -- You received this

Re: Re-open ticket 25192

Yeah, reopening and fixing in 1.11 sounds worth the effort. Thanks Shai! /Markus On Sun, Jan 29, 2017 at 02:12:49AM -0800, Florian Apolloner wrote: On Sunday, January 29, 2017 at 12:02:21 AM UTC+1, Shai Berger wrote: I suggest that we re-open this ticket and solve it in the 1.11.x branch.

Re: Authenticating with Django without the password being sent to the server

That's as correct, Anthony. Any you then want to hash the hash so that you can't just login knowing the hashed password when the database is leaked. Essentially you haven't won anything. Second, how do you make sure the JavaScript is properly transmitted and doesn't contain any code that sends

Consider reverting or adding guidelines on how to use class based views for security sensitive features

and Florian Apolloner, who discovered the issue, are leaning +0 to +1 on the revert of the class-based views. Cheers, Markus Holtermann [1] https://www.djangoproject.com/weblog/2016/nov/21/passwordresetconfirmview-security-advisory/ [2] https://github.com/django/django/pull/7591 -- You

Re: disclosing security release dates on django-announce

While we haven't decided of any particular format, you can expect the announcements to look a bit like https://mta.openssl.org/pipermail/openssl-announce/2016-September/76.html /Markus On Friday, October 7, 2016 at 4:58:00 PM UTC+2, Tim Graham wrote: > > The Django team proposes [0] to

Re: DEP pre-proposal for a simpler URLs syntax.

Thanks for your update, Tom! 1. I think `route` is used in Django Channels (haven't looked it up. Not a real issue but something to think about). I'd prefer `path` instead. 2. Too much magic for my taste. I like the explicit name `typed_url` though (if we stick with `url` as opposed to `path`

Re: DEP pre-proposal for a simpler URLs syntax.

uot; whereas the URL definitions are "just strings" /Markus -- Aymeric. On 04 Oct 2016, at 00:11, Markus Holtermann <i...@markusholtermann.eu> wrote: Thanks for the draft, Tom. I'm a bit concerned that the different `url*()` functions you can import will become confusing.

Re: DEP pre-proposal for a simpler URLs syntax.

Thanks for the draft, Tom. I'm a bit concerned that the different `url*()` functions you can import will become confusing. Can we have `regex_url()` (with chim for `url()`) -- as proposed -- and `simple_url()` instead? /Markus On Mon, Oct 03, 2016 at 02:34:58PM -0700, Tom Christie wrote: Okay

Re: Migration Questioner and String-Type Fields

Thank you for your input, Jarek. Assuming I have an existing model, adding models.CharField(blank=True, max_length=150) to it, doesn't invoke the questioner on current master. Changing this field to models.CharField(max_length=150) doesn't call the questioner either. Looking at the

Re: Migration Questioner and String-Type Fields

Thank you for your input, Jarek. Assuming I have an existing model, adding models.CharField(blank=True, max_length=150) to it, doesn't invoke the questioner on current master. Changing this field to models.CharField(max_length=150) doesn't call the questioner either.

Re: PEP 484 type hinting in Django

Hi Alex, I haven't heard of any discussion on that topic. I'd certainly like to have a DEP before we start implementing it, though. Cheers, Markus On Wed, Aug 17, 2016 at 04:08:29AM +, Alexander Hill wrote: Hi all, I like the plan to include PEP 484 type hinting in Django, outlined in

Re: status of 1.10 release blockers

Thank you for the update, Tim. #26888 will be taken care of by tomorrow. Either Marten or I are pushing a PR. Cheers, /Markus On Thu, Jul 14, 2016 at 06:41:51AM -0700, Tim Graham wrote: I'm planning for the release candidate on Monday. The one blocker is #26888

Re: Possible Bug in RegexURLResolver

Thanks everybody! While Aymeric's sounded great, your reasoning sounds even better, Marten. Thanks! Do you want to provide a PR for that, Marten? Cheers, /Markus On Thu, Jul 14, 2016 at 06:47:15AM -0700, Marten Kenbeek wrote: Using a singleton means that everything is cached for the

Re: Possible Bug in RegexURLResolver

Hey, thanks for posting this here. I opened https://code.djangoproject.com/ticket/26888 to keep track of this. Can I get somebody with threading experience in Python tell me if your proposed patch makes sense? Also, I marked this as a release blocker for 1.10 as I introduced this during a patch

Re: Discussion related to ticket #26822 (new migrations, --keepdb and --parallel option)

Hi, it might be a shot in the dark, but can't we check if Django's testrunner applied new migrations in which case we drop the cloned databases and recreate them. If all migrations already existed we keep the clones the way they are? /Markus On Tue, Jul 05, 2016 at 09:00:25AM +0200, Aymeric

Re: change commit message format to present tense?

I don't mind either way. If everybody seems to use present tense these days, yeah, let's do that as well. As long as the general style of the commit messages stays: Fixes|Refs #12345 -- Make it work My 2¢ /Markus On Fri, Jun 24, 2016 at 11:04:39AM -0600, Jacob Kaplan-Moss wrote: I'm not

Re: Django Integration

What about having asgiref and daphne as optional dependencies instead of hard once and raising a proper exception "please install ..." when the import fails? ``` try: from asgiref import ... except ImportError: raise ImportError( "Please ensure you installed asgiref to use this

Re: Django website ssl-certificate expired

A post-mortem is at https://groups.google.com/forum/#!topic/django-developers/7qzh2n3ZDRc Cheers, /Markus On Wednesday, May 4, 2016 at 11:51:08 AM UTC+2, Marc Tamlyn wrote: > > We are aware of the issue and are working on it. > > Thanks, > Marc > > On 4 May 2016 at 10:30, Wim Feijen

Re: is_authenticated as property

I haven't read the entire thread, did you account for custom user models that don't inherit from AbstractBaseUser? Do the system checks stil work? A Metaclass certainly would not, would it? Cheers, /Markus On Thu, Apr 28, 2016 at 10:56:37AM -0700, Florian Apolloner wrote: Are errors silence

Re: Value of tightening URLValidator/EmailValidator regular expressions?

On Mon, Mar 14, 2016 at 12:34:40PM -0700, Florian Apolloner wrote: On Monday, March 14, 2016 at 8:08:09 PM UTC+1, Michael Manfre wrote: Simple is better. Anyone who needs/wants something more complex is not prevented by Django from doing so. +1 to that and what the rest said ;) +1 As

Re: Choosing migration with relative syntax

Hi Joakim, thank you for your proposal. I don't think this is a good idea because you can easily accidentally undo too many migrations which would inevitably will result in data loss. You don't have the data loss problem in Git as you can always recover by using `git reflog` to go back and

Re: Proposal on Custom Indexes - Google Summer of Code

Hi Akshesh, thank you for your proposal! Sounds like a good plan. On Thursday, March 10, 2016 at 8:16:10 AM UTC+11, akki wrote: Once the index is added to a model, the model can inject itself into the >> index, or the schema editor can use the originating model to get data it >> needs. No

Re: Making max_length argument optional

>From what I understand you will have a hard time doing that at all: On PG could go with a 'max_length=None' in a 3rd party app. But that wouldn't be supported on any other database backend. Which means you're limiting your app to PG. On the other hand you could make your app database

Re: remove old SVN branches from git repository?

I'd like to keep them around somewhere. Even if it's just a wiki page which links to the last commits of each branch. When you have a local checkout of a brach that checkout is staying even if the branch is removed on a remote. Also your local references to remote branches are kept unless you

Re: remove support for unsalted password hashers?

Cheers Tim, looks good to me, assuming the migration actually works :-], haven't tried it out. We probably should advice people that running that migration potentially takes a while, depending on how many passwords they need to update. /Markus On Friday, February 19, 2016 at 3:52:53 AM

Re: Migration Errors (fields.E300)

Hi, Can you please paste the migrations you created that refer to the Channel model. Make sure that those migrations depend on the redis_pubsub.0001_initial migration. /Markus On February 16, 2016 3:41:27 PM GMT+11:00, ayo...@thewulf.org wrote: >I'm having an issue with migrating my Django

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

I think that links to 3rd party pages with grids, comparisons, pros'n'cons, scattered all over Django's documentation aren't too helpful. I'd probably prefer a separate page in the docs that links to those 3rd party pages. The general problem with those sites though, they are not audited for

[#26151] Refactor MigrationWriter.serialize() to use a factory pattern

Hi all, Ticket: https://code.djangoproject.com/ticket/26151 PR: https://github.com/django/django/pull/6059 This pull request suggests to rewrite the serialization in the MigrationWriter to dedicated classes which are then used by a factory function. The reasoning behind this is to reduce the

Re: View permissions to admin

Hi Petr, all, I managed to find some time to look into your PR (updated link: https://github.com/django/django/pull/5297) and the related issue: https://code.djangoproject.com/ticket/8936 . Also, related discussion: https://groups.google.com/d/topic/django-developers/rZ5Pt9R94d4/discussion

Re: does anyone use contrib.auth's "test models"? (CustomUser and ExtensionUser)

Thanks Simon and Tim, I'd be ok with moving them into the tests in 1.10, but would give people a bit more time to see and respond to this discussion. Maybe until Feb 4th, that would be 2 weeks. I haven't seen anybody actually using the models nor do I use them myself. /Markus On Thursday,

Re: Lazy operations refactor regression with abstract models #25858

That's a nice one, Simon. tl;dr: I favor 2; am OK with 1 but against 3. I was favoring 1) as well. But then thought that app relative relationships actually make sense and the current behavior adds a nice new API feature. This way a 3rd party app can provide an abstract model and require you

Re: re-thinking middleware

Thank you Florian and Carl for continuing the work on that topic. I like both the DEP as well as the example. I would, however, include the exception handling in the examples provided in section "Specification" as that is an integral part of middlewares, too. Nitpicking, I would also name the

  1   2   >